W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2015

[whatwg] IPv4 parsing

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 22 Jun 2015 09:52:35 -0700
Message-ID: <CADnb78jrtGmPZ_tYY9K+-zio2D6ZE4H3vB_3tXyvk42T1xQNJg@mail.gmail.com>
To: WHATWG <whatwg@whatwg.org>
Cc: Ryan Sleevi <sleevi@google.com>, Alexey Proskuryakov <ap@webkit.org>, David Walp <David.Walp@microsoft.com>, Mike West <mkwst@google.com>, Valentin Gosu <valentin.gosu@gmail.com>
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 Monday, 22 June 2015 16:53:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:33 UTC