- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 22 Jun 2015 09:52:35 -0700
- 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