[nilved]

Which spec is this? As far as I know `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` was operated as a URL shortener for a while.

[soneil]

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 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/" 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]

I see what you're saying but these all seem like client-side issues to me.

[soneil]

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]

There should be no A-labels on bare gTLDs, so "https://google" should never make sense (per SSAC053 report - https://www.icann.org/groups/ssac/documents)