6 ms·

It would probably work, but it would break spec.

sesutton 10y ago
It definitely works http://ai http://ai. The period needs to be part of the URL at least for Chrome but HN isn't rendering it as part of the link.
- coderobe 10y ago
  the period has to be there because it breaks spec btw
  - nilved 10y ago
    Which spec is this? As far as I know `http://google` http://google` is completely fine, and the period at the end is only necessary for the browser address bar heuristics we're talking about. `http://to` http://to` was operated as a URL shortener for a while.
    - soneil 10y ago
      It's not just browsers. eg; $ host -v ai Trying "ai.home.example.com" Trying "ai" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29228 So if there was a host on my network named 'ai', http://ai http://ai would resolve there (The terminating dot being standard to indicate a fqdn, rather than a browser trick). This has been understood for a long time; rfc1049 gives us: Relative names are either taken relative to a well known origin, or to a list of domains used as a search list. Relative names appear mostly at the user interface, where their interpretation varies from implementation to implementation[.] I stress that last clause; dotless domains have no defined behaviour. "http://google/" http://google/" may refer to google.example.com. (relative to my search list), google.com. (relative to a well-known origin), or google. (a fqdn). That's not browsers, or omnibars, it's been the vagueness of undotted-domains since the start.
      - nilved 10y ago
        I see what you're saying but these all seem like client-side issues to me.
        soneil 10y ago
        Possibly. But with two complications - one is that there is no defined correct behaviour for undotted domains. All the RFC gives us is "implementation vary". Second is that this behaviour is inherited from gethostbyname(), so it's unlikely to change soon.
    - coderobe 10y ago
      There should be no A-labels on bare gTLDs, so "https://google" https://google" should never make sense (per SSAC053 report - https://www.icann.org/groups/ssac/documents https://www.icann.org/groups/ssac/documents)
- bobbyi_settv 10y ago
  In Chrome, the link (without the period) in your comment worked for me
  - sesutton 10y ago
    It turns out it was my DNS settings. It was trying to lookup ai.company-name.com without the period.
- noinsight 10y ago
  Also http://dk http://dk.
mercora 10y ago
I think it breaks policy but not the spec. Technically the root zone has to have NS records. So even records without a label at all should work. of course you can not resolve them without a static zone configuration.

It definitely works http://ai http://ai. The period needs to be part of the URL at least for Chrome but HN isn't rendering it as part of the link.

coderobe 10y ago
the period has to be there because it breaks spec btw
- nilved 10y ago
  Which spec is this? As far as I know `http://google` http://google` is completely fine, and the period at the end is only necessary for the browser address bar heuristics we're talking about. `http://to` http://to` was operated as a URL shortener for a while.
  - soneil 10y ago
    It's not just browsers. eg; $ host -v ai Trying "ai.home.example.com" Trying "ai" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29228 So if there was a host on my network named 'ai', http://ai http://ai would resolve there (The terminating dot being standard to indicate a fqdn, rather than a browser trick). This has been understood for a long time; rfc1049 gives us: Relative names are either taken relative to a well known origin, or to a list of domains used as a search list. Relative names appear mostly at the user interface, where their interpretation varies from implementation to implementation[.] I stress that last clause; dotless domains have no defined behaviour. "http://google/" http://google/" may refer to google.example.com. (relative to my search list), google.com. (relative to a well-known origin), or google. (a fqdn). That's not browsers, or omnibars, it's been the vagueness of undotted-domains since the start.
    - nilved 10y ago
      I see what you're saying but these all seem like client-side issues to me.
      - soneil 10y ago
        Possibly. But with two complications - one is that there is no defined correct behaviour for undotted domains. All the RFC gives us is "implementation vary". Second is that this behaviour is inherited from gethostbyname(), so it's unlikely to change soon.
  - coderobe 10y ago
    There should be no A-labels on bare gTLDs, so "https://google" https://google" should never make sense (per SSAC053 report - https://www.icann.org/groups/ssac/documents https://www.icann.org/groups/ssac/documents)
bobbyi_settv 10y ago
In Chrome, the link (without the period) in your comment worked for me
- sesutton 10y ago
  It turns out it was my DNS settings. It was trying to lookup ai.company-name.com without the period.
noinsight 10y ago
Also http://dk http://dk.

mercora 10y ago

I think it breaks policy but not the spec. Technically the root zone has to have NS records. So even records without a label at all should work. of course you can not resolve them without a static zone configuration.