HTTP, or Hypertext Transfer Protocol, serves as the backbone for data communication across the World Wide Web. It functions as an application-layer protocol designed to transmit hypermedia documents, such as HTML. While its primary role is enabling communication between web browsers and servers, it has versatile applications. HTTP adheres to a classical client-server model, wherein a client initiates a connection to make a request and awaits a response. One key characteristic of HTTP is its stateless nature, where the server retains no data (state) between consecutive requests.
HTTP relies on a system of response codes, each comprising three digits, to communicate the status of a client’s request. These codes are indispensable for interpreting the outcome of an HTTP transaction. They are systematically categorized into ranges, with each range signifying a specific class of response.
The 100 Series: Informational Codes
The 100 series of HTTP status codes indicates that the initial portion of a request has been received by the server and has not been rejected. The server intends to provide a final response after processing the request entirely.
Code 100 – Continue
This interim response directs the client to proceed with the request or disregard the response if the request is already completed.
Code 101 – Switching Protocols
This code is dispatched in response to an Upgrade request header from the client, signaling the server’s intent to transition to a different protocol.
Code 102 – Processing
Code 102 signifies that the server has received the request and initiated processing, although a response is not yet available.
Code 103 – Early Hints (Experimental)
Primarily tailored for use with the Link header, this status code enables the user agent to commence preloading resources while the server readies a response.
The 200 Series: Success Codes
The 200 series of response codes denotes the successful fulfillment of an HTTP request. The most recognized code within this range is “200 OK,” signifying that the server successfully processed the request and is providing the requested data. This series predominantly addresses positive outcomes.
Code 200 – OK
This code confirms that the request has been satisfied.
Code 201 – CREATED
Following a POST command, this code indicates success. However, the response line contains the URI under which the newly created document should be known.
Code 202 – Accepted
The request has been acknowledged for processing, but the processing is ongoing. It may or may not be acted upon in the future, as it may be disallowed when actual processing occurs. Asynchronous operations do not support status returns in this context.
Code 203 – Partial Information
In the response to a GET command, this code signifies that the returned metainformation is not a definitive representation of the object from a server with a copy of the object. Instead, it is from a private overlaid web and may include annotation information about the object.
Code 204 – No Content
This response suggests that no content is available for the request, but the headers remain valuable. The user agent may update its cached headers for this resource with the new ones.
Code 205 – Reset Content
This instructs the user agent to reset the document that sent the request.
Code 206 – Partial Content
Used when the client sends a Range header to request only a portion of a resource.
Code 207 – Multi-Status
This code imparts information about multiple resources, applicable when multiple status codes might be pertinent.
Code 208 – Already Reported
Found within a response element, this code aims to prevent repeated enumeration of internal members of multiple bindings to the same collection.
Code 226 – IM Used
This code signifies the server’s fulfillment of a GET request for the resource, with the response representing the result of one or more instance-manipulations applied to the current instance.
The 300 Series: Redirection Codes
The 300 series of codes informs the client of the necessity for additional actions to complete the request. Notable examples include “301 Moved Permanently” and “302 Found,” guiding the client to a new location for the requested resource. These codes facilitate URL redirection, proving valuable for handling relocated or renamed resources.
Code 301 – Moved Permanently
This code indicates that the URL of the requested resource has permanently changed, with the new URL provided in the response.
Code 302 – Found
Signaling a temporary change in the URI of the requested resource, further URI modifications may occur in the future. The client should continue using this URI for future requests.
Code 303 – See Other
The server responds with this code to instruct the client to retrieve the requested resource at another URI using a GET request.
Code 304 – Not Modified
Employed for caching purposes, this code informs the client that the response remains unaltered, allowing the continued use of the cached response.
Code 305 – Use Proxy (Deprecated)
Formerly part of the HTTP specification, this code indicated that a proxy must be used to access a requested response. It has been deprecated due to security concerns related to in-band proxy configuration.
Code 306 – Unused
This response code is obsolete and reserved. It was used in an earlier version of the HTTP/1.1 specification.
Code 307 – Temporary Redirect
Used when the server instructs the client to obtain the requested resource at another URI using the same method as the prior request. Similar to the 302 Found response code, the user agent must retain the HTTP method used.
Code 308 – Permanent Redirect
This code signifies the permanent relocation of a resource to another URI, indicated by the Location: HTTP Response header. Similar to the 301 Moved Permanently response code, the user agent must retain the HTTP method used.
The 400 Series: Client Error Codes
The 400 series of response codes signifies an issue with the client’s request. The most iconic code is “404 Not Found,” indicating the server’s inability to locate the requested resource. Others, such as “400 Bad Request” for malformed requests and “401 Unauthorized” requiring authentication, empower developers to diagnose and resolve client-related problems.
Code 400 – Bad Request
This code pertains to requests with erroneous syntax or inherently unsatisfiable criteria.
Code 401 – Unauthorized
The message parameter specifies acceptable authorization schemes. The client should reattempt the request with an appropriate Authorization header.
Code 402 – Payment Required
Similar to 401 Unauthorized, this code communicates the acceptability of charging schemes. The client may reattempt the request with a suitable ChargeTo header.
Code 403 – Forbidden
This response indicates that the request pertains to forbidden content, with authorization providing no remedy.
Code 404 – Not Found
This code signifies the server’s inability to locate the requested resource. In a browser, it suggests an unrecognized URL. In an API context, it indicates a valid endpoint but a nonexistent resource. Servers may use this response instead of 403 Forbidden to conceal a resource from an unauthorized client.
Code 405 – Method Not Allowed
The server acknowledges the request method but does not support it for the target resource. For instance, an API may disallow the DELETE method for resource removal.
Code 406 – Not Acceptable
Sent when the web server, after server-driven content negotiation, fails to find content adhering to the user agent’s criteria.
Code 407 – Proxy Authentication Required
Similar to 401 Unauthorized, but here, authentication is mandated via a proxy.
Code 408 – Request Timeout
Sent on idle connections by some servers, indicating a desire to terminate unused connections. This response is more common with browsers like Chrome, Firefox 27+, or IE9, which employ HTTP pre-connection mechanisms to enhance browsing speed. Some servers may simply close connections without sending this message.
Code 409 – Conflict
This code is issued when a request conflicts with the server’s current state.
Code 410 – Gone
Sent when the requested content has been permanently deleted without forwarding. Clients should remove their caches and links to the resource. The HTTP specification suggests this code for “limited-time, promotional services,” with APIs not obligated to employ it for deleted resources.
Code 411 – Length Required
The server rejects the request when the Content-Length header field is undefined and required by the server.
Code 412 – Precondition Failed
This code arises when the client specifies preconditions in its headers that the server cannot meet.
Code 413 – Payload Too Large
This indicates that the request entity exceeds the server’s defined limits. The server might close the connection or provide a Retry-After header field.
Code 414 – URI Too Long
This code signifies that the client’s requested URI exceeds the server’s capacity for interpretation.
Code 415 – Unsupported Media Type
This code indicates that the server does not support the media format of the requested data, leading to the request’s rejection.
Code 416 – Range Not Satisfiable
Used when the Range header field in the request cannot be fulfilled, potentially because the specified range exceeds the target URI’s data size.
Code 417 – Expectation Failed
This response code arises when the server cannot meet the expectation set by the Expect request header field.
Code 418 – I’m a Teapot
The server humorously refuses to brew coffee with a teapot. It’s a nod to the absurd and whimsical side of HTTP. It’s also prone to be both short and stout.
Code 421 – Misdirected Request
This code indicates that the request was directed at a server incapable of producing a response, often due to a mismatch between the scheme and authority in the request URI.
Code 422 – Unprocessable Content
The request is well-structured but cannot be processed due to semantic errors.
Code 423 – Locked
This code suggests that the resource being accessed is currently locked.
Code 424 – Failed Dependency
Issued when a request fails due to the failure of a previous request.
Code 425 – Too Early (Experimental)
Indicates the server’s reluctance to process a request that might be subject to replay.
Code 426 – Upgrade Required
The server declines to fulfill the request under the current protocol but is open to doing so once the client upgrades to an alternative protocol. The server communicates the required protocol(s) using an Upgrade header in the 426 response.
Code 428 – Precondition Required
The origin server mandates conditional requests to prevent the “lost update” problem, where a client GETs a resource’s state, modifies it, and PUTs it back, while a third party alters the server’s state simultaneously, leading to a conflict.
Code 429 – Too Many Requests
This code is triggered when a user sends an excessive number of requests within a defined time frame, often referred to as “rate limiting.”
Code 431 – Request Header Fields Too Large
The server refuses to process the request due to excessively large header fields. Resubmission is possible after reducing the request header field size.
Code 451 – Unavailable For Legal Reasons
This code signifies that the user agent sought a resource that cannot legally be provided, such as a web page censored by a government.
The 500 Series: Server Error Codes
The 500 series encompasses HTTP response codes indicative of server-related issues. Notable among these is “500 Internal Server Error,” pointing to an unforeseen error on the server that obstructed request fulfillment. Others include “502 Bad Gateway,” often encountered in proxy scenarios, and “503 Service Unavailable,” denoting temporary unavailability. These codes serve as valuable indicators for server administrators to identify and address internal issues.
Code 500 – Internal Error
The server confronts an unexpected condition that obstructs the request’s fulfillment.
Code 501 – Not Implemented
This code signifies the server’s lack of support for the required facility.
Code 502 – Service Temporarily Overloaded
When the server grapples with high loads, whether due to HTTP servicing or other requests, it cannot process the request. This condition is usually temporary, with alleviation expected at other times. Ironically, if a server is too overloaded, it may not be able to serve this response.
Code 503 – Service Unavailable
The server is unprepared to handle the request, often due to maintenance or overload. Along with this response, a user-friendly page explaining the issue should be provided. Caching-related headers are crucial for this temporary condition response, typically not meant for caching. The Retry-After HTTP header, if possible, should indicate the estimated recovery time for the service. Webmasters should also consider the caching-related headers in this context.
Code 504 – Gateway Timeout
This response surfaces when the server operates as a gateway and cannot obtain a response within the stipulated time.
Code 505 – HTTP Version Not Supported
This code signifies that the server cannot support the HTTP version used in the request.
Code 506 – Variant Also Negotiates
This code reflects an internal configuration error on the server. The chosen variant resource is configured to engage in transparent content negotiation, rendering it an unsuitable endpoint in the negotiation process.
Code 507 – Insufficient Storage
Issued when the server lacks the capacity to store the representation necessary to fulfill the request.
Code 508 – Loop Detected
The server detects an infinite loop while processing the request.
Code 510 – Not Extended
This code denotes that further extensions to the request are necessary for the server to meet it.
Code 511 – Network Authentication Required
Signifies that the client must authenticate to access the network.