After a POST, should I do a 302 or a 303 redirect?

A common scenario for a web app is to redirect after a POST that modifies the database. Like redirecting to the newly created database object after the user creates it.

It seems like most web apps use 302 redirects, but 303 seems to be the correct thing to do according to the specification if you want the url specified in the redirect to be fetched with GET. Technically, with a 302, the browser is supposed to fetch the specified url with the same method that the original url was fetched with, which would be POST. Most browsers don't do that though.

302 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3

303 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4

So should I be using 302 or 303?

The correct one is 303.

I use it and haven't found any compatibility problems with UAs newer than Netscape 4 (1998, released 17 years ago).

If you use 302, you're risking that UA will re-send POST to the new URL instead of switching to GET.

Still, if you're worried about HTTP/1.0 clients (which don't support vhosts and probably won't be able to access your page anyway) then you should include HTML with link to the new page in body of the 303 response (web servers like Apache do that already).

Depends.
303 and 307 responses were added in HTTP1.1.
So client agents that are strictly compliant to HTTP1.1 RFC should be fine with a 303 response.
But there can be agents that are not fully conformant or are HTTP1.0 compliant and will not be able to handle the 303.
So to be sure that the response of your application can be handled gracefully by the majority of client implementations I think 302 is the safest option.
Excerpt from RFC-2616:

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

In most server-side languages the default redirection mechanism uses 302:

• Java response.sendRedirect(..) uses 302
• ASP.NET response.Redirect(..) uses 302
• PHP header("Location: ..") uses 302
• RoR redirect_to uses 302
• etc..

So I'd prefer this, rather than setting status and headers manually.

In theory, you (and all the world) should be using 303 as you have noted. But also, most browsers react to a 302 like they should react to a 303. So, overall, it seems that it won't matter if you send 302 or 303. In the link you provided for the 303 specification, theres an interesting note:

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

It's important to note the pre-HTTP/1.1 user agents, so maybe this was important a while ago, but I don't believe it is the case now.

So, all in all, it's up to you (I could bet whatever you want that browsers won't change their behavior against 302 statuses never, for fear of breaking the internet for their users).

When providing the location of a new resource created by a POST request, 201 ("Created") is an appropriate response.

HTTP/1.1: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2

Atom Publishing Protocol: https://www.rfc-editor.org/rfc/rfc5023#section-5.3

This does mean that a web browser probably won't redirect to the new URL, though; the user has to follow a link to get to the new item (this link can be provided in the body of the response, as well as in the Location header).