Re: parsing URI (references) according to RFC 3986

On 2011-06-20 02:10, 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:
>>> How does your implementation compare to existing browsers on this test
>>> suite:
>>>
>>> http://trac.webkit.org/browser/trunk/LayoutTests/fast/url/
>>>
>>> In particular, it would be helpful to add entries for your
>>> implementation to the following table so that we can see whether it
>>> makes desirable trade-offs in situations where browsers differ in
>>> behavior:
>>>
>>> https://raw.github.com/abarth/url-spec/master/tests/gurl-results/by-browser.txt
>>
>> The Webkit test suite seems very valuable for its portability and black-box
>> testing capability.  It does have some limitations though in that it's only
>> considering the DOM and sometimes only certain properties therein.
>>
>> I still have a ways to go with my own test suite, but wanted to expand on
>> some of test results.  I've used some of your same test cases where I can.
>>
>> IE canonicalize('http://example.com\\foo\\bar') is
>> 'http://example.com/foo/bar'
>> KR canonicalize('http://example.com\\foo\\bar') is
>> 'http://example.com/foo/bar'
>> SA canonicalize('http://example.com\\foo\\bar') is
>> 'http://example.com/foo/bar'
>> FF canonicalize('http://example.com\\foo\\bar') should be
>> http://example.com/foo/bar. Was http://example.com\foo\bar/.
>>
>> In the above test results, you're comparing against the .href property of
>> the DOM element, which is fine and may be all you want.  It may be
>> interesting to note some more detail here though.
>>
>> FF hostname property for this test is "example.com\foo\bar".  Because it's
>> an invalid hostname it fails to initiate an HTTP request for this URI and
>> doesn't even try to make a DNS request (good).
>>
>> 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.

...breaking

   data:text/plain,foo\bar

?

Received on Monday, 20 June 2011 06:40:35 UTC