Best IT Recipes

After POST should I redirect 302 or 303?

A common scenario for a web application is a redirect after a POST that modifies the database. Like redirecting to a newly created database object after being created by the user.

It looks like most web applications use 302 redirects, but 303 seems to be the right thing according to the specification if you want the URL specified in the redirect to be obtained using GET. Technically, from 302, the browser should get the specified URL in the same way as the original url, which will be POST. However, most browsers do not.

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 use 302 or 303?

+44
Feb 26 '11 at 19:01
source share
5 answers

It depends.
303 and 307 responses were added in HTTP1.1.
Therefore, client agents that strictly comply with the HTTP1.1 RFC should be in order with a 303 response.
But there may be agents that do not fully comply or comply with the requirements of HTTP1.0 and cannot process 303.
Therefore, to make sure that the response of your application can be handled gracefully by most 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 state of things. When interacting with such clients is a concern, Status code 302 may be used instead, as most user agents respond to reaction 302, as described here for 303.

+15
Feb 26 '11 at 19:13
source share

Correct - 303.

I use it and have not found compatibility issues with UAs, newer than Netscape 4 (1998, released 17 years ago ).

If you use 302, you risk UA sending POST to the new URL again instead of going to GET.

However, if you are worried about HTTP / 1.0 clients (which do not support vhosts and probably cannot access your page anyway), you should include HTML with a link to a new page in body 303 (such web servers like Apache did already).

+52
Jul 22 '11 at 10:03
source share

In most server languages, the redirect mechanism uses 302 by default:

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

Therefore, I would prefer this instead of setting the status and headers manually.

+8
Feb 26 '11 at 19:15
source share

In theory, you (and the whole world) should use 303, as you already noted. But also most browsers respond to 302 as if they should respond to 303. Thus, in general, it does not seem to matter if you send 302 or 303. There is an interesting note in the link that you specified for specification 303:

Note. Many user agents prior to HTTP / 1.1 do not understand the status of 303. When interacting with such clients is a concern, the status code 302 can be used instead, as most user agents respond to the response 302, as described here for 303.

It’s important to note the pre- HTP / 1.1 user agents, so maybe this was important some time ago, but I don’t think so.

So, in general, it is up to you (I could bet that you want browsers to never change their behavior against 302 statuses, for fear of hacking the Internet for their users).

+4
Feb 26 '11 at 19:14
source share

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

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

Atom Publishing Protocol: http://tools.ietf.org/html/rfc5023#section-5.3

This means that the web browser will probably not be redirected to the new URL; the user must follow the link to go to the new element (this link can be provided in the response text, as well as in the Location header).

+4
May 08 '12 at 9:59 a.m.
source share


More articles:


All Articles