Re: Non-hierarchical base URLs (was Re: draft-abarth-url-01 uploaded)

On 25.04.2011 09:50, Adam Barth wrote:
> ...
> I don't believe you can correctly account for the behavior of existing
> browsers without classifying schemes into at least two categories.
 > ...

Are browsers consistent in what they do?

> For the purposes of discussion, let's call those two categories
> hierarchical and non-hierarchical (but of course we could use whatever
> names we like).
>
> What does the following HTML alert?
>
> <base href="data://foo/bar?baz#qux">
> <a href="taco.html">hello</a>
> <script>
> alert(document.getElementsByTagName('a')[0].href)
> </script>

By my reading of RFC 3986 it should be

   data://foo/taco.html

I tried with four browsers and got three different answers, all of them 
not the one above.

My conclusion is that browsers do not interoperate on this, so the 
obvious choice would be to try to converge on what the spec says.

> What about the following?
>
> <base href="http://foo/bar?baz#qux">
> <a href="taco.html">hello</a>
> <script>
> alert(document.getElementsByTagName('a')[0].href)
> </script>

As RFC 3986 is agnostic of schemes the answer is

   http://foo/taco.html

> The facts are that URL handling in browser is not uniform across
> schemes.  We might feel happy or sad about that, but that's how things
> are.  If we're going to write specs that tell the truth, then we need
> to acknowledge these infelicities rather than sticking our heads in
> the sand and pretending they aren't the case.

I don't pretend that they are not the case. I just question the 
assumption that there's any interop here. If there isn't this indicates 
that the simplest thing to do is to fix the bugs.

>> I understand what you're doing - rephrasing existing code that you think is
>> good into a spec - but I just don't see how this is helpful if we can't
>> compare the outcome with what the existing specs say.
>
> We can compare the outcome via the test suite and by using our human
> understanding.  Your position seems to be that the only way to write a
> new URL spec is to edit an existing one so that we can understand how
> the two differ.  That's certainly one approach, but it's hardly the
> only approach.

I didn't say that. What I *did* say is that we have an existing spec, 
and if somebody thinks it's wrong then that somebody should provide 
evidence.

(This is a separate discussion from the other deliverables, such as 
preprocessing, API/algorithm entry points etc, error handling etc(.

>> Can we please focus on a test suite first (and yes, I'm doing my homework as
>> well; if you can supply a set of test URIs in machine-readable format that
>> would be super-helpful).
>
> I've been working on a test suite for a while:
>
> https://trac.webkit.org/browser/trunk/LayoutTests/fast/url/
>
> Some other members of the working group have already contributed a
> number of additional test case.  You'll find that all the test URLs in
> that test suite are machine readable.  Rather than continue to discuss
> process, would you like to contribute some additional test cases?

Ok, let me rephrase this. Do you have a set of URIs I can use without 
having to use a JS parser? Plain text? HTML? XML?

Best regards, Julian

Received on Monday, 25 April 2011 08:18:42 UTC