- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 29 Oct 2012 10:00:58 +0100
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: whatwg@lists.whatwg.org
On Sun, Oct 28, 2012 at 6:51 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > Same as the comment I quoted? As same as something else? Same as you quoted. > Well, the Gecko parser preserves the host at this stage assuming the URI was > correctly formatted with a host. Again: > > blah://foo/bar => blah://foo/bar > > The interesting things happen when you have 0, 1, or 3 slashes between ':' > and "foo". The handling of "foo" after this point is a separate issue. Those are handled the same as in Gecko (also matches Safari I think, Chrome strips are starting slashes (like if you have four), but I did not copy that). > In Gecko, it's part of URL parsing. More precisely, it's part of the > normalization performed as part of constructing a "URL" object from a > string. Since this is also how we parse URLs, it's effectively all part of > the package. > > But note that it would be a bit odd of file://c:/ claimed to have a host of > "c" with a default port or some such... Maybe I should introduce a "file host state" that supports colons in the host name (or special case the "host state" further, but the former seems cleaner). Most browsers seem to fail currently on input such as "file://c:/" but this is on a Mac so maybe that's the difference. I would prefer having the parsing be consistent though. > 7 and 8 are not, though at some point we'll need to define equality > comparisons anyway. Yeah, I guess at some point someone would need to write a processing file: URLs specification (for post-parsing operations). On the other hand, it's not entirely clear to me that needs to be interoperable. -- http://annevankesteren.nl/
Received on Monday, 29 October 2012 09:01:26 UTC