W3C home > Mailing lists > Public > uri@w3.org > October 2012

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive@w3.org from September 2012)

From: Jan Algermissen <jan.algermissen@nordsc.com>
Date: Tue, 23 Oct 2012 13:02:04 +0200
Cc: Julian Reschke <julian.reschke@gmx.de>, uri@w3.org
Message-Id: <36CAC0DE-69D1-45BE-996B-7404F26F8422@nordsc.com>
To: Anne van Kesteren <annevk@annevk.nl>

On Oct 23, 2012, at 12:50 PM, Anne van Kesteren wrote:

> On Tue, Oct 23, 2012 at 12:29 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> "whatever you find in a @href" is neither a relative URL nor an absolute
>> URL. I don't think it's helpful to insist on that.
> Nobody is. I plan on defining relative URL/absolute URL only as what
> is valid. The input to the parser can just be href's attribute value.
> As far as developers are concerned, they are to put a relative
> URL/absolute URL as the value of the href attribute,

What Julian is trying to get across is that the content of an @href is a *URI Reference*, not a URI.

You and Ian seem to acidentally or deliberately ignore that distinction. Hence it appears you 'insist' that the value of an @href would be a URI.

And Julian is right. Insisting to ignore that distinction is not helpful because, as Roy already pointed out, the whole discussion is a different one if you were talking about 'fixing parsing of URI references'.


> but indeed nobody
> can prevent them from putting something else in there and as they have
> in legacy pages we need to deal with that somehow.
>> I just tried
>> <html>
>>   <body>
>>      <p>
>>        <a href="/%">Test /%</a>
>>      </p>
>>      <p>
>>        <a href="%">Test %</a>
>>      </p>
>>      <p>
>>        <a href="?%">Test ?%</a>
>>      </p>
>>   </body>
>> </html>
>> and of these, IE doesn't treat the first two as links (it just doesn't send
>> any network request).
> I wish had more easy access to IE to reverse engineer what it's doing.
> Did you test <a>.pathname and such too? If it still sends ?% the point
> that STD 66 is not workable still stands. (And again I just gave
> examples here, to be exhaustive you need to test all prohibited code
> points.) This also does not test the fragment case.
>> That's why I said I'd like to see a concrete list of issues (real and
>> perceived), so that we can test them across browsers and find out whether
>> they *need* to break the spec.
> I did not start out by looking at what is wrong with STD 66 but rather
> with what browsers and to a lesser extent curl/wget etc. are doing.
> Unfortunately I don't have a Windows license. So making such a list of
> issues would take a rather large chunk of my time that given past
> experience I'm not sure is worth it.
> -- 
> http://annevankesteren.nl/
Received on Tuesday, 23 October 2012 11:13:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:16 UTC