Re: [whatwg] URL: spec review - basic_parser

On 10/14/2014 04:57 AM, Anne van Kesteren wrote:
> On Tue, Oct 14, 2014 at 10:37 AM, Sam Ruby <rubys@intertwingly.net> wrote:
>> Given all of the above, would you suggest changing the spec or the expected
>> test results?
>
> You said "The expected results are an object that returns the original
> href, but empty values for all other properties. I don't see this
> behavior in the spec" but that is how the API works (more or less,
> protocol would return ":").
>
> You'd have to explain in a little more detail what you think is wrong
> before I can answer this.

At the present time, all I can say is that the 
https://url.spec.whatwg.org/, 
https://github.com/w3c/web-platform-tests/blob/master/url/, and 
https://github.com/annevk/url are inconsistent.

To illustrate, try pasting http://f:b/c into:

   http://www.lookout.net/test/url/url-liveview.html

Relevant excerpt from that page:

       var url = new URL(input, base);
       urlHref.textContent = url.href;

And the results for http://f:b/c after applying urltestparser.js against 
urltestdata.js is as follows:

{"input":"http://f:b/c","base":"http://example.org/foo/bar","scheme
":"","username":"","password":null,"host":"","port":"","path":"","query":"","fra
gment":"","href":"http://f:b/c","protocol":":","search":"","hash":""}

>>> Looking at the first of those
>>> http://intertwingly.net/stories/2014/10/13/urltest-results/eb3950fcc8
>>> it seems something might be broken here on your end.
>>
>> Can you explain what you think is broken?  It isn't completely obvious, but
>> the input string in that case contains U+200B, U+2060, U+FEFF:
>
> Sure, but 1) per IDNA those are ignored, and 2) urltestdata.txt does
> not contain the output you have for "whatwg".

Perhaps until the inconsistencies are resolved, I shouldn't label 
anything whatwg.  Meanwhile, the testdata results are listed in rows 
marked "testdata".

I'll look further into why the results provided by Opera and 
https://rubygems.org/gems/addressable don't appear to match RFC 3491.

- Sam Ruby

Received on Tuesday, 14 October 2014 09:38:48 UTC