1xx Informational
The request was received and the client should keep going. You almost never send these by hand; the server and the protocol handle them.
The client asked whether to send a large body with Expect: 100-continue, and the answer is yes.
The handshake that upgrades an HTTP connection to a WebSocket.
WebDAV only. The server is still working and wants to stop the client timing out.
Sends Link headers so the browser can start preloading before the real response is ready. Useful, and still rarely deployed.
2xx Success
The request worked. Which one you pick tells the client what to do next, so it is worth being deliberate.
The default success. A body is included and the client should read it.
A POST or PUT made a new resource. Include a Location header pointing at it.
The work is queued, not done. For async jobs: return a URL the client can poll.
A proxy modified the response. You will not send this yourself.
Success with nothing to return, typically a DELETE. The client should not try to parse a body.
Tells the client to clear the form it just submitted. Rare.
A Range request succeeded. This is how video seeking and resumable downloads work.
WebDAV. One response carrying several independent statuses.
WebDAV. The member was already listed elsewhere in this response.
Delta encoding. Effectively unused in the wild.
3xx Redirection
The resource is somewhere else. The difference between these is whether the move is permanent and whether the request method survives.
Several representations exist and the server will not pick. Almost never used.
A permanent move. Cached hard by browsers and passes ranking to the new URL. Getting this wrong is expensive: you cannot un-cache it remotely.
A temporary move. The original URL stays canonical. Historically allowed clients to turn POST into GET.
After a POST, send the client to a GET. This is the Post/Redirect/Get pattern that stops a refresh resubmitting a form.
The client's cached copy is still good. Sent in response to If-None-Match or If-Modified-Since, with no body.
Deprecated for security reasons. Browsers ignore it.
Like 302 but the method and body must be preserved. Use it when a POST has to stay a POST.
Like 301 but the method must be preserved. The strict, modern permanent redirect.
4xx Client error
The request was wrong. Repeating it unchanged will not help, and the response should say enough for the client to fix it.
Malformed syntax: unparseable JSON, a missing required parameter. The catch-all when nothing more specific fits.
Not authenticated, or the credentials were rejected. The name is wrong: it means unauthenticated. Include a WWW-Authenticate header.
Reserved since 1997 and still not standardised. Some APIs use it for billing limits.
Authenticated and still not allowed. Retrying with the same credentials will never work.
No such resource. Also the polite way to hide something that exists but the caller may not know about.
The URL exists but not for this verb. You must include an Allow header listing what is permitted.
Nothing matches the client's Accept header. Most servers just send their default instead.
Like 401, but it is the proxy asking.
The client took too long to send the request. Rare in practice.
The request clashes with current state: a duplicate unique key, or an edit against a stale version.
Deliberately removed and not coming back. Tells search engines to drop it faster than a 404 does.
The server wants a Content-Length and did not get one.
An If-Match or If-Unmodified-Since check failed. The basis of optimistic locking.
The body exceeds the limit. Formerly Payload Too Large.
Usually a GET that should have been a POST, or a redirect loop building up query parameters.
The Content-Type is not one the endpoint accepts. Commonly a missing application/json header.
The requested byte range is outside the file.
The Expect header could not be met.
From an April Fools RFC in 1998. Real, registered, and formally protected from removal in 2017. Do not use it.
The connection reached a server that cannot serve this authority. HTTP/2 connection coalescing.
Well-formed but semantically wrong: valid JSON that fails validation. The right code for a failed form.
WebDAV. The resource is locked.
WebDAV. A previous request in the chain failed.
The server will not risk replaying a request sent in TLS early data.
The client must switch protocols, typically to TLS.
The server insists on a conditional request, to stop the lost-update problem.
Rate limited. Include a Retry-After header, or the client cannot back off properly.
Usually an enormous cookie.
Blocked by law. The number is a Fahrenheit 451 reference, deliberately.
5xx Server error
The server failed. The request may have been perfectly valid, so a client is often right to retry with backoff.
An unhandled exception. Never leak the stack trace to the client; log it and return an opaque message.
The server does not recognize the method at all. Different from 405, which is per-URL.
A proxy got an invalid response from upstream. Usually your app crashed or is not listening.
Temporarily down or overloaded. The correct code for maintenance, and it should carry Retry-After.
Upstream did not answer in time. Often a slow query or an external API hanging.
The protocol version is refused.
A content negotiation misconfiguration.
WebDAV. Out of space.
WebDAV. An infinite loop while processing.
Further extensions are required. Effectively unused.
A captive portal wants you to log in. The hotel wifi code.