by heyjonboy on 7/21/11, 11:00 PM with 27 comments
by pilif on 7/22/11, 3:52 AM
A proxy shouldn't care about a status code in the 300 range, but it might (maybe erroring out on "unknown" codes as part of some security feature).
And then there are scripts quickly thrown together using the HTTP libraries of $LANGUAGE. You'd have to check these too if you use them in a context where you'd also use a 303 redirect.
For what it's worth: my app is serving pages to users behind the worst possible collections of both enterprise and personal firewalls that seem to mangle HTTP headers at will. Heck, I even have more than 10% IE 5.5 users on one installation.
That said, ever since 2004 I have never had one instance of a browser or proxy resubmitting a form in response to a 302 redirect. But many instances of where leaving the trodden path, was causing the strangest unexpected breakages due to severely broken client software.
As such, personally, I will stay with what works and what the RFC is admitting to generally work even if it shouldn't, instead of experimenting with semantics for no visible gain what so ever.
Sounding bitter? Once you witness AV software altering Content-Encoding headers without altering the encoding, you too would get bitter :-)
by shiflett on 7/22/11, 2:34 AM
"If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued."
Does the browser you use do that?
As with cookies, developers go with what works, even if it isn't exactly what the spec says.
History aside, it could be that there is now a difference in how 302 and 303 are interpreted by modern browsers, and I would love to see definitive tests. Any volunteers?
by beaumartinez on 7/22/11, 8:58 AM
This is very pedantic of me, but as of HTTP 1.1, HTTP 302 is Found, not Temporarily Moved[1].
by AgentConundrum on 7/22/11, 3:28 AM
One question I found on a cursory search just now[1] asks whether to use 302 or 303. All three answers submitted to the question recommend 302. The key consideration seems to be backwards compatibility with HTTP 1.0 (the 303 response was apparently added for HTTP 1.1), with the understanding that 302s act close enough to 303s that you don't really need to worry about it. Is this a valid concern, or is this simply an old concern that hasn't died even though the context has changed over the years?
by rfugger on 7/22/11, 5:22 AM
by Getahobby on 7/22/11, 12:47 AM
by afhof on 7/22/11, 1:01 PM
http://hg.python.org/cpython/file/0752215f9f91/Lib/urllib.py...
by deweller on 7/22/11, 2:23 AM
This is another reminder that I should really read the HTTP/1.1 spec someday.
by bigiain on 7/22/11, 12:18 AM
by etaty on 7/22/11, 8:13 AM
by pkteison on 7/22/11, 3:32 AM