Re: parsing URI (references) according to RFC 3986

On 6/23/11 1:55 PM, Bjoern Hoehrmann wrote:
> I do not share this reading of RFC 3986. I would say that the effects of
> using some JavaScript API are up to the definition of that API up to the
> constraints of RFC 3986, which in this case I would read as saying, if
> the argument to window.open is a URL, then
>
>    window.open("#foo")
>
> and
>
>    window.open("http://example.org/#foo")
>
> must be treated the same

I'm fine with that (and in fact, that's the only sane thing to do), but 
then what does section 4.4 even mean in this context?

>> Basically, the spec seems to assume that whatever action you plan to
>> take with the URI immediately follows resolution wrt a base uri, and
>> that this action is known at the time the resolution happens.  It's not
>> clear to me why this assumption is justified.
>
> I do not understand this comment. I would think that RFC 3986, to put it
> this way, defines various Pure functions; and you seem to be concerned
> about what effect state changes have on the pure functions. And by defi-
> nition, pure functions are not affected by state (that's not passed to
> them). So your concern seems to be about something that's not meant to
> be covered by RFC 3986.

I'm not so much interested in what RFC 3986 says, actually, except the 
context of the original question.  The question was: what parts of RFC 
3986 are issues for browser implementors?  I suggested one such part: 
section 4.4 is clearly an issue, since browsers don't actually implement 
it...

-Boris

Received on Thursday, 23 June 2011 18:08:35 UTC