Re: [whatwg] IPv4 parsing

The trailing dot actually had meaning, but in my periodic testing most
commerce websites didn't handle it well. It didn't help that browsers never
favored adding it.

On a somewhat (user) hostile network, http://discover.com/ might go to
http://discover.com.example.com/ this probably isn't what the user wanted
(it certainly wasn't what I wanted when I tested), but using
http://discover.com./ got unfortunate redirects or unhappy responses from
the remote server.

These days with HSTS, mobile phones, and hopefully some future ubiquitous
VPN, we can ignore the risks of hostile local DNS/DHCP servers.

Also fun and probably worth documenting is how http://127.1/ and
http://127.2.1/ are parsed. I doubt the average developer knows (unless
they specifically deal with low level networking).

You have http://0.0.0.66/ that's not a match for your example...
On Jun 22, 2015 12:52 PM, "Anne van Kesteren" <annevk@annevk.nl> wrote:

> I've done some research into how Chrome parses IPv4 addresses to see
> if that's worth standardizing.
>
> Most browsers do not have special parsing rules for IPv4 vs domain
> names. That is, they pass the "domain name" to the network layer and
> let that figure out what should happen. Typically, that results in a
> URL such as http://0x42。0./ (note the 。 and trailing .) to end up
> connecting to IPv4 address 66.0.0.0 with 0x42.0. in the Host header.
> The resulted parsed URL will be http://0x42.0./.
>
> Chrome will instead have 66.0.0.0 in the Host header and its parsed
> URL will have that value too. That means you lose functionality
> Host-header wise, but it is more predictable (and no longer depends on
> the networking stack) where you connect to. That seems somewhat more
> secure, since it might not be entirely obvious that e.g. http://0x42./
> is not a domain name. If the resulting URL is http://0.0.0.66/ it's
> very clear what is going on. And we don't depend on whatever the OS
> networking library does.
>
> Now, is that what we want? Is losing the trailing dot acceptable?
>
>
> --
> https://annevankesteren.nl/
>

Received on Wednesday, 24 June 2015 10:46:37 UTC