Subject: Issue 43 (combining fragments)

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Jul 2009 12:25:27 +0200

Hi,

looking at <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>:

"At present, the behavior in the case where there was a fragment with 
the original URI, e.g.: http://host1.example.com/resource1#fragment1 
where /resource1 redirects to 
http://host2.example.com/resource2#fragment2 is 'fragment1' discarded? 
Do you find fragment2 and then find fragment1 within it? We don't have 
fragment combination rules."

And the proposal:

"Could add note to Location header that combining fragments may have 
unpredictable results."

I just tested this with various browsers.

- Firefox and Safari use the fragment in the location header.

- Opera uses the fragment from the source URI, when present, otherwise 
the fragment from the redirect location

- IE (8) ignores the fragment in the location URI, thus will use the 
fragment from the source URI, when present

Proposal:

"Note: the behavior when fragment identifiers from the original URI and 
the redirect need to be combined is undefined; current User Agents 
indeed differ on what fragment takes precedence."

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 28 Jul 2009 17:32:20 +0200

> fragment combination rules."

And we don't allow fragments in Location or Content-Location either,
with both referencing absoluteURI and not URI-reference. Neither 2068,
2396 or 3986 (in the form of absolute-URI) allows fragments in this
production.

So imho it's sufficient to just say that the behavior is unspecified if
you return any other forms of URIs including those with fragments, if
anything at all needs to be said on the subject.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 28 Jul 2009 17:36:16 +0200

> 2396 or 3986 (in the form of absolute-URI) allows fragments in this

My error. Forgot that we had changed Location to reference URI instead
of absolute-URI.

So my question in light of what has been seen, should that change stay
or should we revert back to absolute-URI as used by 2068 and 2616 moving
the use of fragments back into the "undefined" field?

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Jul 2009 17:42:20 +0200

> the use of fragments back into the "undefined" field?

They are used in practice, and their behavior *is* defined in case the 
original URI didn't have a fragment.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 28 Jul 2009 17:54:16 +0200

> the use of fragments back into the "undefined" field?

Reading back on the history of this thanks to archive.org restoring the
old unofficial errata list and the references from there the decision to
allow fragments in Location when used in redirects seem to be fairly
well accepted, and also that the meaning is unspecified when both the
original request URI and the Location URI has fragments.

As the server generating the redirect can not know if there was a
fragment or not in the URI accessed by the user I would even say that in
general the behavior is undefined when returning a fragment in Location.

It should also be noted that not even the HTTP/1.0 production for
Location do allow for fragments.

Regards
Henrik

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 29 Jul 2009 15:39:43 +0200

> the fragment from the redirect location

Regarding Opera:

We changed the behaviour in 2003 (about v7.20) because we got several  
reports requesting that particular change, and apparently the reporters  
were able to accomplish what they wanted in other browsers at the time,  
one claimed also that our old behaviour was not according to 2616.

If you clarify the entry, you should be very clear on the point that any  
and all anchors (including no anchor) overrides any anchor used by the  
initial resource when presenting the URL to the user or using it to  
process the resource, or under which conditions an override should be  
allowed, alternatively that it is not specified (which would probably be  
unsatisfactory).

This is another area which could benefit from actual examples in the  
specification (as I have metioned for cache directives).

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Jul 2009 11:35:08 +0200

Yngve N. Pettersen wrote:
> On Tue, 28 Jul 2009 12:25:27 +0200, Julian Reschke 
> <[email-masked]> wrote:
> 

Indeed.

So I just put together a set of tests that use absolute URIs, paths (see 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/185>), and combined 
them with frag ids. See <http://greenbytes.de/tech/tc2231/redirects.html>.

The UAs I tested behaved consistently, except for the Opera issue noted 
above.

That being said, the UAs unfortunately are also consistent in ignoring 
the fragment when it appears in a relative-ref, not a URI; this is 
really bad as I wouldn't want to require different behaviors depending 
on where the fragment identifier was in.

Thus, *if* we address issue 43 by mandating that the fragment from the 
Location header overrides a previous one, that should also apply for the 
case of relative-refs, in which case all UAs would need to be fixed (sigh!).

BR, Julian