making interoperability decisions (was Re: parsing URI (references) according to RFC 3986)

On 6/19/2011 5:10 PM, Adam Barth wrote:
> On Sun, Jun 19, 2011 at 4:18 PM, Chris Weber<chris@lookout.net>  wrote:
>> On 6/18/2011 6:09 AM, Adam Barth wrote:
>>
>> In a similar test case "http://example.com/foo\bar" both FF and Opera's path
>> property in the DOM percent-encode the "\" as "/foo%5Cbar" and the
>> corresponding HTTP request matches to become "GET /foo%5Cbar HTTP/1.1".  IE,
>> Chrome, and Safari all instead convert the "\" to a "/".  Their DOM path
>> property shows "/foo/bar" and the HTTP request matches as "GET /foo/bar
>> HTTP/1.1".
>
> 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.
>
> Adam
>

3987bis does say this in 
http://trac.tools.ietf.org/html/draft-ietf-iri-3987bis-05#section-7.2:

    5. Convert backslashes ('\') matching href-path-sep to forward
        slashes ('/').

And HTML5 says the same in it's section on Resolving URLs 
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#resolving-urls

    12. If result uses a scheme with a server-based naming authority, 
replace all U+005C REVERSE SOLIDUS (\) characters in result with U+002F 
SOLIDUS (/) characters.


Regarding interoperability decisions - has consensus previously been 
made among the WG members as to how a behavior-difference should be 
resolved?  In a case like treating a "\" as a "/", would the most 
reasonable decision be based on how many of the 5 most popular Web 
browsers are doing it, or would it be based on market share, or 
something else?

For example, if only IE and Firefox treated "\" as "/", would that be 
reason to write such behavior into the spec?  (considering those two 
together claim > 50% total market share).  Or what if the case was 
Opera, Safari, and Chrome - 3 out of the 5 but still < 50% combined 
market share.

Best regards,
Chris

Received on Monday, 20 June 2011 04:35:55 UTC