Be really careful with this. While all browsers out there speak http 1.1 by now and thus should support 303 redirects, many proxy servers are still living in http 1.0 land.<p>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).<p>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.<p>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.<p>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.<p>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.<p>Sounding bitter? Once you witness AV software altering Content-Encoding headers without altering the encoding, you too would get bitter :-)
This post seems to be based on the belief that everything adheres to the spec. Historically, 302 has always been interpreted like 303 is defined, and never like 302 is defined. For example:<p>"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."<p>Does the browser you use do that?<p>As with cookies, developers go with what works, even if it isn't exactly what the spec says.<p>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?
> <i>Ruby, Python, and PHP default to an HTTP 302 (Temporarily Moved) redirect.</i><p>This is very pedantic of me, but as of HTTP 1.1, HTTP 302 is <i>Found</i>, not <i>Temporarily Moved</i>[1].<p>[1] <a href="http://tools.ietf.org/html/rfc2616#section-10.3.3" rel="nofollow">http://tools.ietf.org/html/rfc2616#section-10.3.3</a>
Are there any significant drawbacks to using a 303 over a 302 redirect? I ask because I've seen this advice a number of times before - typically on StackOverflow - and I've seen a lot of recommendations to use 302.<p>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?<p>[1] <a href="http://stackoverflow.com/q/5129076/1588" rel="nofollow">http://stackoverflow.com/q/5129076/1588</a>
Django had a ticket for this, and it got closed as wontfix because 302 redirects are known to work fine:<p><a href="https://code.djangoproject.com/ticket/13277" rel="nofollow">https://code.djangoproject.com/ticket/13277</a>
The sample PHP code can be done with one call to the header function using the second parameter which allows you to set the http response code. Nice article though, learned something new today.
If it makes a difference, Python's urllib handles 301, 303, and 307 with the 302 handler. It also speaks 1.0<p><a href="http://hg.python.org/cpython/file/0752215f9f91/Lib/urllib.py#l661" rel="nofollow">http://hg.python.org/cpython/file/0752215f9f91/Lib/urllib.py...</a>
Wikipedia has a good schema explaining this :
<a href="http://en.wikipedia.org/wiki/Post/Redirect/Get" rel="nofollow">http://en.wikipedia.org/wiki/Post/Redirect/Get</a>