Re: parsing URI (references) according to RFC 3986

On 6/19/2011 8:56 PM, Boris Zbarsky wrote:
> On 6/19/11 8:10 PM, Adam Barth wrote:
>> Indeed. The point is that IE, Chrome, and Safari treat \ as if it
>> were / in parsing URLs whereas Firefox does not. I suspect we'll want
>> the spec to say that \ should be treated like / when parsing URLs.
>
> As a note, Gecko treats \ as / in when parsing URIs with the scheme
> "file" in builds compiled for Windows and OS2. We don't do that in any
> other circumstances.
>
> -Boris

I can validate what you're saying in the DOMs parsing.  It looks like 
other browsers do the same, with the exception of Opera which 
percent-encodes the "\" as %5C.  Here are my results for 
"file://c:/0111\foo"

RawUrl				Browser
file:///C:/0111/foo		Chrome/12.0.742.100
file:///c:/0111/foo		MSIE 7.0
file:///c:/0111/foo		Firefox/4.0.1
file://c:/0111/foo		Safari/533.21.1
file://localhost/c:/0111%5Cfoo	Opera/9.80

>
> P.S. In Gecko's case, also on Windows and OS2, for urls that parse like
> "file" (ones where we don't expect an authority section), there's some
> sort of magic to detect that things like "file://c:/foo" or
> "file://c|/foo" is actually to be parsed as something with host = "" and
> file path "/c|/foo" as opposed to something with host "c:" or "c|". I
> have no idea whether other UAs do something similar...
>

It seems a little scary if I understand what you're saying correctly. 
More scary perhaps is that when I test "file://c|/0110/foo" I see in the 
DOM parsing that IE and Chrome both convert the "|" to the ":".

RawUrl				Browser
file:///c:/0110/foo		MSIE 7.0
file:///C:/0110/foo		Chrome/12.0.742.100
file:///c|/0110/foo		Firefox/4.0.1
file://c|/0110/foo		Safari/533.21.1
file://localhost/c|/0110/foo	Opera/9.80


-Chris

Received on Monday, 20 June 2011 05:32:55 UTC