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

Mark Nottingham <mnot@mnot.net> Tue, 28 June 2011 05:36 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 B7FA621F8607 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 27 Jun 2011 22:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.932
X-Spam-Level:
X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJ5Mfao3S9hQ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 27 Jun 2011 22:36:32 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 66D7C21F8606 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 27 Jun 2011 22:36:32 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1QbQnA-0000yJ-It for ietf-http-wg-dist@listhub.w3.org; Tue, 28 Jun 2011 05:24:56 +0000
Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <mnot@mnot.net>) id 1QbQn4-0000ww-3a for ietf-http-wg@listhub.w3.org; Tue, 28 Jun 2011 05:24:50 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by aji.keio.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1QbQmz-0002lM-2j for ietf-http-wg@w3.org; Tue, 28 Jun 2011 05:24:49 +0000
Received: from chancetrain-lm.mnot.net (unknown [118.209.116.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 97D4E509D9 for <ietf-http-wg@w3.org>; Tue, 28 Jun 2011 01:24:16 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1084)
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <EA6B8FDD-735E-4435-958E-CEC26698C610@mnot.net>
Date: Tue, 28 Jun 2011 15:24:13 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <94928AC7-A53D-41AA-B8D0-FA633AAC64F4@mnot.net>
References: <6A53E99A-019D-4F6D-A33D-24524CD34E17@mnot.net> <BANLkTinkgsBO6JhWZUGWhGu+6DRidLwLog@mail.gmail.com> <479CAD406474484E8FA0E39E694732C017C0C353@DF-M14-03.exchange.corp.microsoft.com> <EA6B8FDD-735E-4435-958E-CEC26698C610@mnot.net>
To: httpbis Group <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: aji.keio.w3.org 1QbQmz-0002lM-2j 5ed5131f1151bb0b27104e4f81a52878
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/94928AC7-A53D-41AA-B8D0-FA633AAC64F4@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/10795
X-Loop: ietf-http-wg@w3.org
Sender: ietf-http-wg-request@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: <E1QbQnA-0000yJ-It@frink.w3.org>
Resent-Date: Tue, 28 Jun 2011 05:24:56 +0000

I haven't heard any negative responses, so marking for incorporation into -15.


On 28/05/2011, at 11:07 AM, Mark Nottingham wrote:

> Thanks, Eric -- that's very helpful.
> 
> Speaking just about #295 for the moment, does anyone have a concern about defining the behaviour as in draft-bos-http-redirect? 
> 
> Cheers,
> 
> 
> On 28/05/2011, at 10:58 AM, Eric Lawrence wrote:
> 
>> I've filed an issue in our database for consideration in IE10.
>> 
>> Having HTTPBIS clearly call for this behavior will definitely help support the case for making a change.
>> 
>> thanks,
>> Eric Lawrence
>> 
>> -----Original Message-----
>> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of Adam Barth
>> Sent: Thursday, May 26, 2011 8:46 PM
>> To: Mark Nottingham
>> Cc: httpbis Group
>> Subject: Re: #295: Applying original fragment to "plain" redirected URI (also #43)
>> 
>> My understanding is that preserving the fragment across the redirect is a net positive for compatibility on the web.  In fact, Eric's blog post mentions that he learned about the behavior by investigating compat problems that IE faces because it lacks this behavior.  I certainly agree that it would be nice to make the specs less cloudy in this regard.  :)
>> 
>> Adam
>> 
>> 
>> On Thu, May 26, 2011 at 8:32 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>> New issue: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295>
>>> 
>>> As Eric Lawrence pointed out on his blog:
>>> 
>>> http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-a
>>> nd-redirects-anchor-hash-missing.aspx
>>> 
>>> 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:
>>> http://tools.ietf.org/html/draft-bos-http-redirect-00
>>> 
>>> 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 <https://gist.github.com/330963>*, 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 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/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.
>>> 
>>> This makes me wonder if we should, given this new information, re-open #43 and define precedence rules for fragment combination upon redirects. Thoughts?
>>> 
>>> Regards,
>>> 
>>> 
>>> * Note that the "PASS/FAIL" terminology in those tests is misleading, as it assumes the semantics defined in draft-bos-http-redirect.
>>> 
>>> ** IE 6-9 are interesting, in that the location bar URI does not reflect the fragment, nor is it available in JavaScript's location.hash; however the document *does* scroll to the appropriate place on the page when following the link.
>>> 
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/