Re: parsing URI (references) according to RFC 3986

On 2011-06-23 19:06, Boris Zbarsky wrote:
> On 6/23/11 1:02 PM, Julian Reschke wrote:
>> Is your concern that not all kinds of normalization are allowed?
>
> No, not at all.
>
> My concern is that the entire section is not really something that
> belongs in a URI spec. See below.
>
>>> P.S. I also happen to think that the requirements of section 4.4 are
>>> insane, which is why there is no interop on it.
>>
>> There isn't? I think we need more examples.
>
> <img src="#foo"> doesn't follow section 4.4 in any browser I'm aware of,
> as one example. Nor should it, imo.

All that 4.4 says is that the effect is that you do not need to retrieve 
the resource again:

"When a same-document reference is dereferenced for a retrieval action, 
the target of that reference is defined to be within the same entity 
(representation, document, or message) as the reference; therefore, a 
dereference should not result in a new retrieval action."

Test case: <http://greenbytes.de/tech/tc/uris/imgsame.html>

You are right, Firefox does something bizarre; it indeed sends a GET 
request for http://greenbytes.de/tech/tc/uris/imgsame.html#foo (note 
that fragment identifier in the request URI).

Chrome and IE *do* send a second request, but at least they get the URI 
right.

Now is the concern the fragment identifier (which seems to be a specific 
problem of Firefox), or the fact that browsers do a refetch?

In the latter case -- why does it happen? Are there sites that do conneg 
here, and which actually do send different content when they see that 
the request originates from an <img> tag???

> I think the best course of action here is to remove 4.4 altogether and
> let specifications that actually have a concept of "document" define
> what should happen with URIs in various circumstances instead of trying
> to create blanket definitions and behavior prescriptions that don't
> actually work in many situations.

Or, leave it in (I'm pretty sure there's a good reason for it), but 
state that there may be cases where the context may require refetching 
the resource.

(we do agree that the advice holds for <a> links inside HTML, right?)

Best regards, Julian

Received on Thursday, 23 June 2011 17:24:11 UTC