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

Julian Reschke <julian.reschke@gmx.de> Sat, 07 January 2012 15:57 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA4D21F8565 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 7 Jan 2012 07:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.317
X-Spam-Level:
X-Spam-Status: No, score=-7.317 tagged_above=-999 required=5 tests=[AWL=3.282, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzdWjwTkXKCN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 7 Jan 2012 07:57:55 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7E46D21F84F9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 7 Jan 2012 07:57:55 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1RjYcY-0007LJ-OK for ietf-http-wg-dist@listhub.w3.org; Sat, 07 Jan 2012 15:55:50 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <julian.reschke@gmx.de>) id 1RjYcQ-0007KU-45 for ietf-http-wg@listhub.w3.org; Sat, 07 Jan 2012 15:55:42 +0000
Received: from mailout-de.gmx.net ([213.165.64.22]) by maggie.w3.org with smtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1RjYcO-00035s-6r for ietf-http-wg@w3.org; Sat, 07 Jan 2012 15:55:42 +0000
Received: (qmail invoked by alias); 07 Jan 2012 15:28:34 -0000
Received: from p3EE26DB9.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.109.185] by mail.gmx.net (mp032) with SMTP; 07 Jan 2012 16:28:34 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/0aIVIaUb01NlT80wMXhOhP/qYWwTHC7NUT5WmbP MYnTzJQPi+Q97l
Message-ID: <4F08649E.6060107@gmx.de>
Date: Sat, 07 Jan 2012 16:28:30 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Larry Masinter <masinter@adobe.com>, Mark Nottingham <mnot@mnot.net>, httpbis Group <ietf-http-wg@w3.org>
References: <6A53E99A-019D-4F6D-A33D-24524CD34E17@mnot.net> <4EFDFA17.4080804@gmx.de> <4F031419.1050708@gmx.de> <C68CB012D9182D408CED7B884F441D4D06121B5AE5@nambxv01a.corp.adobe.com> <4F0608AB.20808@gmx.de> <EDB1544B-C4AE-41CA-806A-15FD1956D467@gbiv.com>
In-Reply-To: <EDB1544B-C4AE-41CA-806A-15FD1956D467@gbiv.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=213.165.64.22; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1RjYcO-00035s-6r 0d247ffa68f828a23282b2c6e52c9fe2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #295: Applying original fragment to "plain" redirected URI (also #43)
Archived-At: <http://www.w3.org/mid/4F08649E.6060107@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/11987
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1RjYcY-0007LJ-OK@frink.w3.org>
Resent-Date: Sat, 07 Jan 2012 15:55:50 +0000

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