See Other
Production Risk
Low. It is a best practice for handling form submissions (the Post/Redirect/Get pattern) and prevents common issues like duplicate form submissions.
The server sent this response to direct the client to get the requested resource at another URI with a GET request. It is primarily used to redirect the client to a success or confirmation page after a POST request has been successfully processed.
- 1After a user submits a form via POST, the server redirects them to a success page to prevent re-submission if the user refreshes.
- 2An API endpoint that creates a resource via POST redirects the client to the newly created resource's URL.
- 3Separating a POST action from the subsequent GET view.
A user submits a contact form via POST, and the server redirects them to a 'Thank You' page.
POST /contact-us HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded name=John&message=Hello
expected output
HTTP/1.1 303 See Other Location: /thank-you
Fix
Use 303 for the Post/Redirect/Get (PRG) pattern
WHEN After successfully handling a POST request to prevent form re-submission on refresh
# After processing POST /checkout: HTTP/1.1 303 See Other Location: /order-confirmation?id=12345
Why this works
303 forces the browser to issue a GET request to the Location URL. This breaks the POST-on-refresh cycle — if the user refreshes /order-confirmation, the browser does a GET, not a repeat POST. The POST action is not repeated.
✕ Use 302 instead of 303 after a POST
302 is ambiguous about whether the redirected request should use GET or the original method. 303 is explicit: always GET. Most browsers do follow GET anyway with 302, but 303 is semantically correct and unambiguous.
Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev