W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: issue 325: When are Location's semantics triggered?, was: Protocols/APIs and redirects

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 14 Dec 2011 21:58:23 +1100
Cc: Julian Reschke <julian.reschke@gmx.de>, Cameron Heavon-Jones <cmhjones@gmail.com>, "Roy T. Fielding" <fielding@gbiv.com>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-Id: <1017506B-E1FA-4B5B-87D8-C0E513A46254@mnot.net>
To: Willy Tarreau <w@1wt.eu>
Hi Willy,

How is Safari's behaviour more like handling 302 than 300? 300 states:

>    If the server has a preferred choice of representation, it SHOULD
>    include the specific URI for that representation in the Location
>    field; user agents MAY use the Location field value for automatic
>    redirection.

Also, the use cases you talk about could be addressed by using a header other than Location (i.e., omitting Location from a 3xx response), just as 304 does.


On 14/12/2011, at 5:43 PM, Willy Tarreau wrote:

> Hi Mark,
> On Wed, Dec 14, 2011 at 03:47:46PM +1100, Mark Nottingham wrote:
>> Do we have agreement that a 3xx + Location can / should trigger an automatic redirect (taking into account user notification -- a separate issue)?
> While I have no strong feeling about it, I still think it's not the best
> idea for the long term. While Julian suggests Safari's behaviour is good,
> I'd see it differently, considering that it handles 3xx like 302 and
> differently from 300 (in fact, only Chrome seems to be consistent between
> 3xx and 300 in Cameron's tests).
> The only thing I don't like with saying that Location will be usable with
> all 3xx is that it basically means that we won't create any new 3xx anymore,
> because once we have the various basic redirects, we'll stop there. Without
> suggesting an automatic redirect, we could imagine that later we'd add a
> status with multiple Location headers and let the user pick one, or another
> status indicating a unsafe/expensive locations which require user approval,
> or any such thing. If we perform the automatic redirect, we'll refrain from
> adding such codes, or we'll have to invent a new header.
> For instance, imagine that all the user manual of your mobile phone is
> supposed to be accessible from within it, with some pages cached inside
> and other ones outside. You could have a small server in it which either
> serves the cached pages when it has them (or redirects to their local
> filesystem location using 301), or suggests a redirect to the external
> site to fetch them. But you wouldn't necessarily want the user to
> retrieve large amounts of data from the net without being aware of it,
> since it can be very expensive depending where you are. A user-approved
> redirect would perfectly make sense here.
> Another example I'm facing very often is that developers working on
> http+https applications generally need to know both the protocol used
> and the host, while it's not always easy where the app is located.
> Adding new extensions which would mean "redirect to same host using
> https" or "same scheme with host xxx" or even "same host + port XYZ"
> would sometimes help a lot. I'm not sure we'll be able to add them
> after suggesting an automatic rule.
> Once again, I have no strong feeling about it and I'm not a browser
> developer, but I'm just trying to keep some rope for future additions.
> If everyone else is OK with the automatic redirect on 3xx, I won't insist.
> If I had the choice, I'd rather suggest either that a UA MAY automatically
> redirect, or that it SHOULD redirect with user approval ; both options would
> keep server implementers from inventing their own codes every day, without
> blocking evolutions.
> Best regards,
> Willy

Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 14 December 2011 10:58:51 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:26 UTC