303 See Other
The result of the request is at another URL that should be fetched with GET, whatever method was originally used.
Status
HTTP/1.1 303 See Other
Details
- Category: 3xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 9110 §15.4.4
- Cacheable: Only with explicit cache headers
- Response body: Allowed
- Retry: Safe to retry
303 is the post-redirect-get pattern in protocol form. A POST creates or updates something, the server answers 303 with the location of the result, and the client fetches it with GET. Refreshing the resulting page is then harmless because it repeats a GET rather than the original POST.
Unlike 302, the method rewrite is required rather than tolerated, which makes 303 the correct choice whenever you deliberately want the follow-up request to be a GET.
Headers
- Location: Required. The URL to fetch with GET.
Common causes
- A form submission completed and the server redirected to a confirmation page.
- An asynchronous job finished and the client was pointed at the result resource.
Usage notes
For clients
- Issue a GET to the Location URL and drop the original request body.
- Do not resend the POST body to the new URL. That is the mistake 303 exists to prevent.
For servers
- Use 303 rather than 302 after non-idempotent requests so browser refreshes are safe.
- Point Location at a stable result URL the user can bookmark.
Examples
Post, redirect, get
HTTP request
POST /orders HTTP/1.1 Host: shop.example.com Content-Type: application/x-www-form-urlencoded sku=ABC&qty=2
HTTP response
HTTP/1.1 303 See Other Location: /orders/5521/confirmation