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

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]."""


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

Mark Nottingham

Received on Friday, 30 December 2011 00:43:45 UTC