HTTP status code, method and header reference
Status codes, methods and headers — searchable, no tab-switching to MDN.
Client should continue with the request body.
Server is switching protocols per the Upgrade header.
Preload hints sent before the final response.
Request succeeded; response body carries the result.
Resource created — return its URI in the Location header.
Accepted for processing, but not yet completed.
Success with no response body. Common for DELETE/PUT.
Range request satisfied; partial body returned.
Resource permanently moved; clients should update links.
Temporary redirect (method may change to GET).
Redirect to a GET on another URI, typically post-POST.
Cached copy is still valid (ETag/If-None-Match).
Temporary redirect preserving the original method.
Permanent redirect preserving the original method.
Malformed syntax or invalid request framing.
Authentication required or failed. (Really "unauthenticated".)
Authenticated but not permitted to access the resource.
No resource matches the URI.
Method not supported — respond with an Allow header.
State conflict, e.g. a duplicate or version mismatch.
Resource intentionally removed and will not return.
A conditional request header evaluated false.
Content-Type not supported by the endpoint.
Short and stout. From RFC 2324, an April Fools spec.
Syntactically valid but semantically invalid — validation errors.
Rate limited; pair with Retry-After.
Unhandled server-side failure.
Server does not support the functionality required.
Invalid response from an upstream server.
Temporarily overloaded or down for maintenance.
Upstream server did not respond in time.
About the HTTP reference
How it works in 4 steps · 4 common use cases · 3 questions answered
About the HTTP reference
How it works in 4 steps · 4 common use cases · 3 questions answered
How it works
- 1.Type into the filter to search across status codes, methods and headers at once.
- 2.Codes are grouped by class — 2xx success, 3xx redirect, 4xx client error, 5xx server error.
- 3.Methods list whether they are safe and idempotent, which is what decides if a client may retry.
- 4.Headers give what each one is for rather than a restatement of its name.
Common use cases
- •Deciding between 400, 409 and 422 for a validation failure
- •Checking whether PUT or PATCH is the idempotent choice for a retryable write
- •Looking up what Retry-After expects when rate-limiting a client
- •Settling whether a redirect should be 301, 302, 307 or 308
FAQ
409 or 422 — which should I return?
409 Conflict means the request clashes with the current state of the resource, such as a duplicate key or a stale version. 422 Unprocessable Content means the request was well-formed but its contents failed validation. If retrying the same request unchanged could succeed later, it is usually 409.
What does idempotent actually guarantee?
That making the same request twice leaves the server in the same state as making it once. It says nothing about the response body being identical, and it is why a client may safely retry PUT or DELETE but not POST.
When is 307 or 308 the right redirect?
When the method must be preserved. Historically 301 and 302 caused clients to turn a POST into a GET; 308 and 307 are the permanent and temporary equivalents that forbid that rewrite.