Skip to content

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

Specifications

See also