Subject: Re: TAG resolution on redirection with fragment identifiers

From: Julian Reschke <[email-masked]>
Date: Sun, 05 Dec 2010 13:46:29 +0100

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 [email-masked] & 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
> [email-masked], 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

---

From: Noah Mendelsohn <[email-masked]>
Date: Sun, 05 Dec 2010 11:02:43 -0500

On 12/5/2010 7:46 AM, Julian Reschke wrote:
> 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)?

TAG members, what do you think?  It would be nice to agree this without 
further telcon time if possible.  Thank you.

Noah

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Dec 2010 10:03:29 +0100

> WG ok with sticking with this position (not specifying the rule)?

Hi,

change applied with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1097>.

I believe that this ticket can be closed once the next set of drafts is 
published, unless we change our mind and *want* to specify a rule for 
recombination.

Best regards, Julian

---

From: Yves Lafon <[email-masked]>
Date: Mon, 13 Dec 2010 05:59:28 -0500 (EST)

>> WG ok with sticking with this position (not specifying the rule)?

As some browsers are already using a default rule in the case of HTML, 
either we delegate to the HTML specification, or we define a rule for HTML 
fragment ourselves (bad, IMHO), or we define a default rule if nothing 
else is applicable (probably the best option).

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves