HTTP Status Reference

Defined for WebDAV in RFC 2518 and removed again by RFC 4918; the registry still lists it with RFC 2518. A final response is expected later.

An interim response. Its headers, such as a Link preload, are only hints; the server is likely to send a final response, which carries its own status and headers.

A temporary registration for the resumable uploads draft. It expires on 2026-11-13 unless extended, and the draft may still change.

Says only that the HTTP request succeeded. What the body means depends on the method and the application; an API may report an error inside a 200 body.

What to check: Read the response body for an application-level result.

The request was accepted, but processing has not finished and may still be refused or fail. HTTP has no way to send the final status later.

What to check: Look in the response for a status URL or job ID and check it later.

The overall status of a WebDAV response that carries a separate status for each resource; some of those operations may have failed.

What to check: Read the status of each response element in the body.

Permanent move to the URI in Location. For historical reasons a client may change POST to GET when following it; 308 does not allow that change.

What to check: Check the Location header.

Temporary redirect to the URI in Location; keep using the original URI. For historical reasons a client may change POST to GET; with 307 the client must keep the method.

What to check: Check the Location header.

Points to another resource holding the result, to be fetched with GET or HEAD; typical after a form POST. The new URI does not replace the original.

Not an error: the answer to a conditional GET or HEAD, saying the client's stored copy is still valid, so no body is sent.

What to check: If an old version is shown, check the validators (ETag, Last-Modified) and the If-None-Match / If-Modified-Since request headers.

Deprecated since RFC 7231 (Appendix B).

Temporary redirect. Unlike 302, a client that follows it automatically must not change the request method.

Permanent redirect. Unlike 301, it does not allow changing the request method from POST to GET.

Despite the name, this is about authentication: credentials are missing or were not accepted. The response must carry a WWW-Authenticate challenge.

What to check: Check the WWW-Authenticate header and the credentials or token that were sent.

Reserved for future use. There is no standard meaning, so any use is specific to the application.

The server understood the request but refuses it. A client should not automatically repeat it with the same credentials, and the refusal may have nothing to do with credentials.

What to check: Look for a reason in the response body.

Nothing was found, or the server prefers not to reveal that something exists; a server may hide a forbidden resource this way. It does not say whether the absence is temporary or permanent.

What to check: Check the host, path and method of the request.

The request content is larger than the server will process. Formerly named "Payload Too Large" (RFC 7231).

What to check: A Retry-After header indicates that the condition is temporary and when to try again.

Reserved because the "I'm a teapot" code of the April 1 RFC 2324 was deployed as a joke so often. It has no standard meaning.

The request reached a server that cannot answer for this URI, for example over a connection reused for a different host name. The client may retry over a new connection.

The content type and syntax are fine, but the instructions in the body cannot be processed. Formerly named "Unprocessable Entity" (RFC 4918).

The server is unwilling to risk processing a request that might be replayed. It concerns TLS early data, which the client or an intermediary on the way (signalled by the Early-Data header) may have used. Any retry must not be sent in early data.

Rate limiting: too many requests in a given time.

What to check: A Retry-After header, if present, says how long to wait.

A generic error for an unexpected server-side condition; the code alone does not tell the cause.

What to check: Check the server or application logs at the time of the request.

A gateway or proxy received an invalid response from an upstream server. The code alone does not show whether the cause lies in the upstream server, the path to it or the proxy itself, nor whether the request played a part.

What to check: Check the proxy's error log and the state of the upstream server.

Temporary overload or maintenance. Some overloaded servers refuse the connection instead of sending 503.

What to check: A Retry-After header, if present, says when to retry.

A gateway or proxy did not get a timely response from the upstream server. The upstream may still be processing the request or may already have done so.

What to check: Check the upstream response time and the proxy's timeout setting before retrying a request that changes data.

Obsoleted: the HTTP Extension Framework of RFC 2774 was moved to Historic, and the registry marks the code as obsoleted.

Intended for intercepting proxies, such as a captive portal on public Wi-Fi, to ask for a network login. Origin servers should not send it.