Re: #295: Applying original fragment to "plain" redirected URI (also #43)

On 2012-01-05 22:48, Roy T. Fielding wrote:
> Sorry, I'm not following this logic at all.  Reusing the original fragment
> after a redirect is, at best, fallback behavior that would occur *inside*
> the user agent renderer after URI parsing is done, after the redirect is
> done, and without any reference to the Location URI.  In short, this whole
> approach is wrong (and confusing).
> ...

OK, I think I see what you mean.

Going back to what we currently have in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.9.5.p.3>:

"The field value consists of a single URI-reference. When it has the 
form of a relative reference ([RFC3986], Section 4.2), the final value 
is computed by resolving it against the effective request URI 
([RFC3986], Section 5)."

and in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.9.5.p.9>:

"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."

(which was the result of negotiating the text with the W3C TAG, see 
issue #43).

The note we added back then already mentions fragment identifiers on the 
"original URI".

We need to decide whether to re-open #43 (fragment recombination), and 
what to do #295.

The three interesting cases are:

(1) <http://greenbytes.de/tech/tc/httpredirects/#tfnry>: 
http://example.com/test1 redirect-to http://example.com/test2#A yields ?

(2) <http://greenbytes.de/tech/tc/httpredirects/#tfyry>: 
http://example.com/test1#B redirect-to http://example.com/test2#A yields ?

(3) <http://greenbytes.de/tech/tc/httpredirects/#tfyrn>: 
http://example.com/test1#B redirect-to http://example.com/test2 yields ?

Browsers agree on the first two cases (the fragment from the redirect is 
used, so http://example.com/test2#A), but do not completely agree on the 
last case (Safari and IE loose the fragment identifier, the others keep 
it, ending up with http://example.com/test2#B).

I think we have heard from IE that they want to change to the 
Firefox/Chrome/Opera behavior. We don't know about Safari.

To make this change we could add to:

"The field value consists of a single URI-reference. When it has the 
form of a relative reference ([RFC3986], Section 4.2), the final value 
is computed by resolving it against the effective request URI 
([RFC3986], Section 5)."

saying

"... If the original URI, as navigated to by the user agent, did contain 
a fragment identifier, and the final value does not, then the original 
URI's fragment identifier is added to the final value."


(and also we would kill 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.9.5.p.9>).

Best regards, Julian

Received on Saturday, 7 January 2012 15:55:42 UTC