Http Status Codes Guide
This guide covers what really matters in http Status Codes Guide: concepts, context, limits and interpretations that often cause confusion.
The central topic is http Status Codes Guide, the value is in understanding the correct interpretation, not only repeating a result.
Interpreting an IP, domain, port or vendor without checking scope and source. The fix usually starts by cross-check the result with the source, update window and infrastructure layer..
401 (Unauthorized) means valid authentication is missing, you must identify yourself, and sending correct credentials fixes it. 403 (Forbidden) means you are authenticated but not allowed to access the resource; re-authenticating will not help. In practice, 401 asks for a login and 403 signals a lack of authorization even when already logged in.
The main point is understanding http Status Codes Guide in the right context instead of treating one isolated value as a complete answer.
A typical limitation is assuming that one identifier alone explains the entire environment.
Cross-check http Status Codes Guide with source, conventions, freshness and practical goals before taking action.
The client should continue sending the request body (after Expect: 100-continue).
The server agrees to switch protocols (e.g. upgrade to WebSocket).
Lets the client preload resources (Link headers) before the final response.
Standard success. The body depends on the method (GET returns the resource).
A resource was created; usually accompanied by a Location header.
Request accepted for async processing; not yet completed.
Success, but an intermediate proxy modified the content of the origin server’s original response.
Success with no response body (common for DELETE and PUT).
Success with no body; tells the user agent to reset the form or view that triggered the request.
Partial response to a request with a Range header (downloads, video).
The resource has more than one representation; the client should pick one. Rarely used in practice, with no standardized format for automatic selection.
The resource permanently moved; update links and bookmarks.
Temporary redirect; the method may change to GET in practice.
Look at another resource using GET (Post/Redirect/Get pattern).
The cached resource is still valid (ETag/If-Modified-Since); use the cache. The response itself carries no content, so RFC 9110 does not list it as cacheable by default the way it does 200.
Temporary redirect that preserves the method and body.
Permanent redirect that preserves the method and body.
The server could not understand the request due to malformed syntax or invalid data.
Valid authentication is missing. Despite the name, it is about authentication, not permission.
Reserved for future use by RFC 9110. Some payment APIs reuse it non-standardly to signal a pending charge.
Authenticated but not allowed to access the resource. Re-authenticating will not help.
The resource does not exist at this URL (or the server hides its existence).
The HTTP method is not allowed on this resource (see the Allow header).
No representation matches the client’s Accept header.
Like 401, but the authentication required is for a proxy, not the origin server.
The client took too long to send the complete request.
Conflict with the current state of the resource (e.g. concurrent edit).
The resource existed and was permanently removed.
The server refuses the request without a defined Content-Length.
A precondition sent by the client (If-Match, If-Unmodified-Since, etc.) evaluated to false on the server.
The request body is larger than the server is willing to accept.
The URL is too long (usually a huge query string on a GET).
The request body Content-Type is not supported by the endpoint.
The range requested in the Range header could not be satisfied (common in resumed downloads and video streaming).
A server along the path could not meet the expectation in the Expect header (e.g. 100-continue).
A 1998 joke (RFC 2324/7168, the HTCPCP protocol). RFC 9110 now formally lists the code as reserved (“Unused”) because of how widely it has been deployed as a joke, so it cannot be given serious semantics; it is nonetheless still widely implemented as an easter egg across frameworks and tools.
The request reached a server that cannot give an authoritative response for that origin, common when an HTTP/2 connection is reused across different domains.
Syntax is fine, but the semantics are invalid (business validation failed).
The resource is locked (WebDAV extension), common in file storage and collaborative-editing services.
The request failed because another request it depended on failed first (WebDAV extension).
The server refuses to process data sent too early (0-RTT anti-replay).
The client must switch to a different protocol (e.g. newer TLS).
The server requires a precondition (e.g. If-Match) to avoid lost updates.
Rate limit reached. Check the Retry-After header before retrying.
The headers (or a single cookie) are too large.
Content blocked for legal reasons (censorship, DMCA, GDPR).
A generic, unexpected server error. Check the backend logs.
The server does not support the functionality required (e.g. the method).
A proxy/gateway got an invalid response from the upstream server.
The server is temporarily unavailable (overload or maintenance).
A proxy/gateway did not get a response from upstream in time.
The HTTP version used in the request is not supported.
A content-negotiation configuration error: the chosen variant also negotiates, creating a loop the server has to break.
The server lacks storage to complete the request (WebDAV).
The server detected an infinite loop while processing a WebDAV request with unlimited depth (Depth: infinity).
You must authenticate to the network (Wi-Fi captive portals).
This is an offline reference: nothing is sent over the network. The tool does not access any site or make requests, it only explains the codes.