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 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.
This interim response directs the client to proceed with the request or disregard the response if the request is already completed.
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 signifies that the server has received the request and initiated processing, although a response is not yet available.
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 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.
This code confirms that the request has been satisfied.
Following a POST command, this code indicates success. However, the response line contains the URI under which the newly created document should be known.
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.
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.
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.
This instructs the user agent to reset the document that sent the request.
Used when the client sends a Range header to request only a portion of a resource.
This code imparts information about multiple resources, applicable when multiple status codes might be pertinent.
Found within a response element, this code aims to prevent repeated enumeration of internal members of multiple bindings to the same collection.
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 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.
This code indicates that the URL of the requested resource has permanently changed, with the new URL provided in the response.
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.
The server responds with this code to instruct the client to retrieve the requested resource at another URI using a GET request.
Employed for caching purposes, this code informs the client that the response remains unaltered, allowing the continued use of the cached response.
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.
This response code is obsolete and reserved. It was used in an earlier version of the HTTP/1.1 specification.
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.
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 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.
This code pertains to requests with erroneous syntax or inherently unsatisfiable criteria.
The message parameter specifies acceptable authorization schemes. The client should reattempt the request with an appropriate Authorization header.
Similar to 401 Unauthorized, this code communicates the acceptability of charging schemes. The client may reattempt the request with a suitable ChargeTo header.
This response indicates that the request pertains to forbidden content, with authorization providing no remedy.
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.
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.
Sent when the web server, after server-driven content negotiation, fails to find content adhering to the user agent’s criteria.
Similar to 401 Unauthorized, but here, authentication is mandated via a proxy.
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.
This code is issued when a request conflicts with the server’s current state.
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.
The server rejects the request when the Content-Length header field is undefined and required by the server.
This code arises when the client specifies preconditions in its headers that the server cannot meet.
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.
This code signifies that the client’s requested URI exceeds the server’s capacity for interpretation.
This code indicates that the server does not support the media format of the requested data, leading to the request’s rejection.
Used when the Range header field in the request cannot be fulfilled, potentially because the specified range exceeds the target URI’s data size.
This response code arises when the server cannot meet the expectation set by the Expect request header field.
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.
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.
The request is well-structured but cannot be processed due to semantic errors.
This code suggests that the resource being accessed is currently locked.
Issued when a request fails due to the failure of a previous request.
Indicates the server’s reluctance to process a request that might be subject to replay.
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.
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.
This code is triggered when a user sends an excessive number of requests within a defined time frame, often referred to as “rate limiting.”
The server refuses to process the request due to excessively large header fields. Resubmission is possible after reducing the request header field size.
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 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.
The server confronts an unexpected condition that obstructs the request’s fulfillment.
This code signifies the server’s lack of support for the required facility.
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.
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.
This response surfaces when the server operates as a gateway and cannot obtain a response within the stipulated time.
This code signifies that the server cannot support the HTTP version used in the request.
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.
Issued when the server lacks the capacity to store the representation necessary to fulfill the request.
The server detects an infinite loop while processing the request.
This code denotes that further extensions to the request are necessary for the server to meet it.
Signifies that the client must authenticate to access the network.
