W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] URL decomposition on HTMLAnchorElement interface

From: Kartikaya Gupta <lists.whatwg@stakface.com>
Date: Sat, 28 Mar 2009 14:11:38 +0000
Message-ID: <20090328141139.958048DB002D@zapata.dreamhost.com>
On Fri, 27 Mar 2009 21:53:48 -0400, Boris Zbarsky <bzbarsky at MIT.EDU> wrote:
> Kartikaya Gupta wrote:
> > The empty string falls under the "anything else" case in my suggestion above and would work as you expect.
> 
> Null and empty string should, imo, have the same behavior here.  It 
> doesn't make sense to treat them differently to me.

Do you agree that null and empty string should behave differently for "search" and "hash"? To me, it doesn't make sense to treat null and the empty string differently for some components but not others.

> 
> > > There are big scary comments in the Gecko code for these setters saying 
> > > that they must never ever throw.  I suspect that making them throw would 
> > > be a serious web compat issue.
> > 
> > Is this Gecko-internal code you're referring to? Or the setters exposed to web 
> > content via HTMLAnchorElement?
> 
> The latter.  The Gecko-internal URI code does in fact throw on a lot of 
> these setters, and the HTMLAnchorElement methods catch and eat these 
> exceptions, very much on purpose.

Ok. I'll assume there is valid reasoning behind that. Replace all the "throw"s with "be silently ignored" in my proposal.

> > > Changing from an authority to a non-authority URI or the other way 
> > > around doesn't seem desirable to me (and would only work for unknown 
> > > schemes anyway, presumably, at best; it's better if it just never works).
> > 
> > Does it matter? Since it's an unknown scheme, it's basically opaque data. You can't 
> > dereference it and fetch the resource it points to
> 
> No, but you can pass it off to a helper application.  In any case, my 
> comment above was more concerned with your proposal that one should be 
> able to create a non-authority http: URI than about unknown schemes.

I don't think my proposal allowed creation of a non-authority http: URI. I said that 'Attempts to set "host" to null for a scheme known to require an authority should throw.' Since http is a scheme known to require an authority, you wouldn't be able to null out the authority. The one loophole I missed would be to create a non-http non-authority URI and then change the scheme to http. That can be fixed by amending the first sentence of my proposal to the following:

- Attempts to set "protocol" to null, the empty string, or anything containing invalid characters (i.e. not in the "scheme" production of RFC3986) should throw. Setting it to a scheme known to require an authority when the authority component is null should also throw. Setting it to a scheme known to require no authority when the authority component is non-null should also throw. Setting it to anything else should be allowed and should update the scheme component of the underlying URI.

(With appropriate adjustments of s/throw/be silently ignored/)

Cheers,
kats
Received on Saturday, 28 March 2009 07:11:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT