[shiflett]

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:

"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?

[heyjonboy]

I've noticed older versions of Firefox trying to resubmit form data when refreshing after a 302 redirect.

Granted there aren't many people running old versions of Firefox, but why risk it? Even if 302 is generally interpreted like a 303, it's safer to just use a 303.

[shiflett]

Safer? The risk is that 303 is misinterpreted, and this risk is why we have always used 302. I'd need evidence before taking a chance based on someone's recollection of an older version of Firefox.

RFC 2616 mentions early misinterpretations; they are why 303 and 307 exist:

"Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client."

Recommending 303 sounds like a great idea, but the spec's description of 303 is what 302 is in practice, and the latest spec (2616) makes note of this reality. Also, consistent support for 303 is not a sure bet:

"Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303."

Without evidence, using 303 is the riskier option.

[heyjonboy]

"Note: Many pre-HTTP/1.1 user agents do not understand the 303 status."

The fact is there really aren't any pre-HTTP/1.1 browsers still in use. See: http://serverfault.com/questions/110932/are-there-internet-u...

Given that many web apps these days require javascript and CSS and HTTP/1.1 is over 12 years old, I don't think it's realistic to worry about clients that only support HTTP/1.0.

While 302 works in practice, it's safer to use 303, which works by definition.

[dangrossman]

The problem is that the browser is not the only client involved. Corporate/country/personal proxies, firewalls and antivirus software all sit in between some servers and clients, some of them still do not handle HTTP/1.1 correctly, and many of them will alter your headers in transit.

As your StackOverflow link mentions, Squid, a widely used proxy, is still only fully implemented for HTTP/1.0.

[pornel]

Corporate/country/personal proxies, firewalls and antivirus software don't perform redirects themselves, so they are irrelevant for status 303 support.

Today all clients that send HTTP/1.0 version support more than HTTP/1.0, e.g. HTTP/1.1 Host header is basically mandatory on the web.

HTTP/1.1 compliance requires some harder things like pipelining support, and full HTTP/1.1 caching proxy has a lot of hairy stuff to deal with (strong/weak cache validators, stitching of partial responses, Vary support, etc.).

You can have quite decent HTTP/1.1 implementation that still doesn't deserve to be called full HTTP/1.1.

[yuhong]

Yea, browsers old enough to not send a Host header are pretty much unusable on today's web without a proxy.