Re: TAG resolution on redirection with fragment identifiers

On 30.11.2010 16:49, Noah Mendelsohn wrote:
> The TAG has recently considered some questions relating to the case
> where a Web client dereferences a link of the form (A#B), sends the
> request as usual with a Request-URI of "A", and the HTTP response contains:
>
> * A status code of 30x (redirection)
> * A Location header with a fragment identifier (e.g. C#D)
>
> Thus, both the original reference and the returned location are to what
> RFC 3986 [1] calls "Secondary Resources". On it's teleconference of 18
> November 2010, the TAG reached the following conclusion:
>
> ===
> RESOLVED: The TAG endorses the health warning "If you deploy a 30x
> Location: C#D, then be aware that anyone who creates a URI A#B, might be
> inconvenienced (since there are no fragment combination rules)."
> ===
>
> I was assigned TAG ACTION-503: on - Noah Mendelsohn - Publicize to
> www-tag ietf-http-wg@w3.org & chairs health warning on secondary resourc
> redirection as resolved on 18 Nov 2010 - Due: 2010-11-25 - OPEN
>
> This note is in fulfillment of that action. (I will send separately to
> chairs@w3.org, to avoid cross posting to public and member-only lists).
>
> Thank you very much
> ...

Hi Noah,

thanks for the feedback. Let's see what the current draft says in 
<http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#section-9.4>:

-- snip --
       Note: This specification does not define precedence rules for the
       case where the original URI, as navigated to by the user agent,
       and the Location header field value both contain fragment
       identifiers.
-- snip --

We could extend that text like that:

-- snip --
       Note: This specification does not define precedence rules for the
       case where the original URI, as navigated to by the user agent,
       and the Location header field value both contain fragment
       identifiers.  Thus be aware that including fragment identifiers
       might inconvenience anyone relying on the semantics of the
       original URI's fragment identifier.
-- snip --

So this is just a clarification of the current spec's position. Is the 
WG ok with sticking with this position (not specifying the rule)?

Best regards, Julian

Received on Sunday, 5 December 2010 12:47:05 UTC