[whatwg] URL: file: URLs
Anne van Kesteren
annevk at annevk.nl
Mon Oct 29 02:00:58 PDT 2012
On Sun, Oct 28, 2012 at 6:51 PM, Boris Zbarsky <bzbarsky at 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.
More information about the whatwg