- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 29 Dec 2011 19:43:15 -0500
- 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 UTC