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

Julian Reschke <> Fri, 30 December 2011 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4713D21F8510 for <>; Fri, 30 Dec 2011 09:52:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.574
X-Spam-Status: No, score=-7.574 tagged_above=-999 required=5 tests=[AWL=3.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id seKgNYOmQmBO for <>; Fri, 30 Dec 2011 09:52:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9E28A21F8801 for <>; Fri, 30 Dec 2011 09:52:58 -0800 (PST)
Received: from lists by with local (Exim 4.69) (envelope-from <>) id 1Rggcc-0005TF-Sz for; Fri, 30 Dec 2011 17:52:02 +0000
Received: from ([]) by with esmtp (Exim 4.69) (envelope-from <>) id 1RggcR-0005R1-SC for; Fri, 30 Dec 2011 17:51:51 +0000
Received: from ([]) by with smtp (Exim 4.72) (envelope-from <>) id 1RggcQ-0003AA-5C for; Fri, 30 Dec 2011 17:51:51 +0000
Received: (qmail invoked by alias); 30 Dec 2011 17:51:23 -0000
Received: from (EHLO []) [] by (mp008) with SMTP; 30 Dec 2011 18:51:23 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19wR5YD9tBwo6FihVzm+kNOUGqW1MspKnim4g+jjo e9V+N5hJuvDjWe
Message-ID: <>
Date: Fri, 30 Dec 2011 18:51:19 +0100
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Mark Nottingham <>
CC: httpbis Group <>, Larry Masinter <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=;;
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: 1RggcQ-0003AA-5C 8ecb249d2460f3d4d6a11e5528b013fb
Subject: Re: #295: Applying original fragment to "plain" redirected URI (also #43)
Archived-At: <>
X-Mailing-List: <> archive/latest/11946
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>
Resent-Message-Id: <>
Resent-Date: Fri, 30 Dec 2011 17:52:02 +0000

On 2011-05-27 05:32, Mark Nottingham wrote:
> New issue:<>
> As Eric Lawrence pointed out on his blog:
> we don't define what happens when a request-URI has a fragment identifier and is redirected, but the Location header payload doesn't.
> As mentioned in #43, an old I-D did specify behaviour here:
> Specifically:
> """
> If the server returns a response code of 300 ("multiple choice"), 301 ("moved permanently"), 302 ("moved temporarily") or 303 ("see other"), and if the server also returns one or more URIs where the resource can be found, then the client SHOULD treat the new URIs as if the fragment identifier of the original URI was added at the end.
> """
> By my testing<>*, IE (6 to 9)** and Safari do not apply the fragid (T4 and T8), whereas Opera, Chrome and Firefox do. If anyone has results from other implementations, they'd be most welcome.
> I see two possible ways forward:
>    1) As with #43, explicitly state that there isn't interop here.
>    2) Define interop along the lines of draft-bos-http-redirect.
> I realise that #2 would break some existing implementations, but I've seen evidence of some real interop pain here, and defining interop where the spec is cloudy *is* within our charter.
> However, I'd really like to hear from implementers as to whether they'd be willing to change their implementations before going down that path.
> Regarding #43<>, my most recent testing indicates that, putting aside T4 and T8, there *is* interop on fragment combination for IE6-9, Safari 5, Chrome (current), FF4, FF3.6.15, FF3.0.11, and Opera 11.10.

Indeed; see my tests at 
<> (note that 
Safari appears to have funny issues filling the iframes; but navigating 
to the linked resource gets you proper results).

And, in a later mail:

>> My concern is similar to what was brought up in the context of issue 43 -- it's not entirely clear whether HTTPbis has any business in defining this (that is; is this an aspect of media types or of redirects?).
>> I don't think we ever came to a conclusion about this in the context of #43, as, in the end, we didn't define the behavior.
> My recollection was that we didn't have interop in browsers, and we didn't have an indication of a strong desire from them one way or the other. I'd say we have both now.
> Perhaps we should ping the TAG to get their thoughts? Absent strong objection, it seems like we can have an easy interop win here.

We could try (cc'ing Larry so he sees this), but we'd need a reply very 
soon :-)

Best regards, Julian