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: Thu, 29 Dec 2011 19:43:15 -0500
Message-Id: <65D52A6A-0D0C-473E-87E4-3E4400651361@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
One other thing --

p2 already has:

> For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource.

There was equivalent text in 2616. So, I think the resolution here is actually pretty minor; we just need to add text to p2 7.3 that reflects this; e.g.,

"""A Location header on a 3xx response indicates that a client MAY automatically redirect to the URI provided; see [ref to Location header]."""

Comments?



On 14/12/2011, at 5:58 AM, Mark Nottingham wrote:

> 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.
> 
> Cheers,
> 
> 
> 
> 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/
> 
> 
> 
> 

--
Mark Nottingham
http://www.mnot.net/
Received on Friday, 30 December 2011 00:43:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:51 GMT