HTTP response codes
Status codes, also known as HTTP response status codes, are three-digit codes sent by a server in response to a client’s request made via a web browser. These status codes provide a shorthand way for the server to explain the status of a client’s request and the action it took in response. Codes from the Internet Engineering Task Force’s Request for Comments (RFCs) and other specifications, as well as some other codes used in typical HTTP applications, are also included.
The authoritative registry of HTTP status codes is managed by the Internet Assigned Numbers Authority (IANA). The first digit of an HTTP status code indicates the category of the code, while the remaining two digits are used to specify the type of answer that falls under the category specified by the first number. According to the nature of the server’s response, HTTP status codes are grouped into the following five classes:
- 1XX – Informational codes. Indicative of successful receipt and comprehension of a request. A temporary one is issued while the request is being processed. The client is notified that they must now wait for a definitive answer. An empty line follows the header fields and the status line to indicate the end of the message.\
- 2XX – Success codes. The client’s request was received, interpreted, and approved as described. This indicates that the request sent by the client was valid and that the server fulfilled its obligations in a timely manner.
- 3XX – Redirection codes, which may necessitate further action on the part of the requesting client. The extra step typically entails sending the customer to a different web address. The majority of these status codes are employed in URL rerouting.
- 4XX – Issue codes. Issue code indicates that the request could not be processed because the client reported an internal error. Lack of authority, incorrect syntax, etc., could be present in the request. In the event of a mistake, the server should add an object detailing the nature of the problem and whether or not it is a temporary situation.
- 5XX – Error codes. The server encountered an unexpected condition or cannot complete the requested operation and returned an error code. The server should include an object explaining the error situation and whether or not it is transitory (unless when replying to a HEAD request).
The most typical HTTP response status codes are detailed here.
Informational codes
100 Continue code
To proceed with the request or skip it if it has already been completed, the browser should see this status code.
This notifies the client that the server has received and is processing the request’s first segment. In either case, the browser must send the remaining parts of the request or disregard it if the request has already been fulfilled. After processing a request in full, the server is required to deliver a concluding response. In order to deliver the body of a request after receiving a 100 Continue status code, a browser must first specify Expect: 100-continue in the request header.
101 – Switching Protocols
If a browser sends an Upgrade request header, and the server returns a 200 OK response code, it means the server is willing to switch the application protocol used in the connection. Additionally, an Upgrade response header will be included in the response to show which protocol the server upgraded to.
Changes to the protocol are only allowed when doing so would be beneficial, such as when upgrading to a newer version of HTTP or when delivering resources that need real-time or synchronous communication.
103 – Early Hits code
When combined with the Link header, this status code tells the user-agent (such as a browser) to begin preloading resources while the server completes a response.
Success codes
200 OK
With this response code, it is safe to assume that your request was processed without error. Success is defined differently for each HTTP method:
The data you requested was sent in the body of the response when you performed a GET request.
With a HEAD response, only the representation headers are sent, with no body.
The answer to a POST request will always be the resource explaining the action’s outcome.
This is a trace request, thus the server has included the original request message in its reply.
In many cases, the response to a PUT or DELETE request will not be 200 OK, but rather 204 No Content or 201 Created, depending on whether or not the resource has previously been uploaded. Caching is enabled by default on a 200 answer.
201 Created
This response code means that the resource was successfully created in response to the request. In order to return the 201, the server must first build the resource. If the request’s URI or Location header specifies a location for the newly returned resource, that location will be used.
202 Accepted
The request has been accepted for processing, but neither the completion nor the initiation of processing has occurred, as indicated by this status code. The request may or may not be fulfilled depending on whether or not it is approved at the time the request is processed.
The 202 disposition is indecisive. Its goal is to release the user agent’s connection to the server so that the server can accept a request for another process (such as a batch-oriented process). Therefore, HTTP cannot deliver a status code to indicate the result of executing the request at a later time. However, the answer will detail the request’s current status and either direct the user to a status monitor or provide an estimated completion time.
203 Non-Authoritative Information
While the request was fulfilled, the payload was altered from the original 200 OK response by a transforming proxy. In addition, the header meta information that is delivered is not the final, authoritative set as it appears on the origin server, but rather it is compiled from a local or third-party copy. Cached responses of status code 203 can be reused.
204 No Content
If a request is successful but does not require a body to be returned, the client can stay on the same page and not receive a 404 Not Found error. Because there is nobody in a 204 response, it always ends on the first empty line following the header.
However, any new or updated metainformation will be applied to the browser’s active page. This answer is designed to allow input for actions to take place without creating a change to the active page. Like when adding the ability to “save and continue editing” on a wiki. It would be saved with a PUT request, and the 204 response status code would signal that the editor should not be overwritten. It is normal to be able to cache a 204 answer (an ETag header is included in such a response).
Redirection 300 Codes
300 – Multiple Choices
There are multiple possible responses to the request, as shown by this status code. Either the user agent or the user must make a decision. Except in the case of a HEAD request, the user will be presented with a selection of resource attributes and locations in the response.
The browser’s capabilities and the nature of the format being used determine the ease with which the optimal option can be chosen automatically. Location contains the URI for the server’s preferred representation, which can be used by the browser to automatically switch to that representation. This response code is rarely used because there is no standard method for selecting one of the responses. Normally, you can cache a response with status code 300.
301 Permanently Moved
The requested resource has been permanently relocated to the specified URI, as indicated by this status code. The response’s Location field contains the permanent URI. HEAD requests will result in a brief hypertext notice linking to the new URI in the response (s). Requests made with methods other than GET and HEAD will not be redirected with a 301 status code until the user confirms the redirect. This is because changing the request’s context could affect the response.
Since method switching is forbidden with a 301 status, the 308 Permanent Redirect status code is advised for POST requests instead. By default, a 301 answer can be stored in a cache.
302 Found
Any time you get this status code, know that the requested resource has been temporarily relocated to the URI. Response’s Location field contains the temporary URI. HEAD requests will result in a brief hypertext notice linking to the new URI in the response (s). The request will not be redirected with a 302 status code for methods other than GET and HEAD until the user confirms the redirect.
The 302 status code should only be used as a response for GET or HEAD methods, as changing the method is specifically forbidden for this status; instead, the 307 Temporary Redirect status code should be used if the method is changed during the redirection process. Use 303 See Other when you want to request that GET be substituted for the original method. For example, you may use it to send a confirmation message like “you successfully uploaded XYZ” in response to a PUT request rather than the uploaded resource itself. If the Cache-Control or Expires header is present in a 302 response, the response can be cached.
303 See Other
Instead of leading to the freshly uploaded resources, this status code indicates that the redirects lead to a user-defined page (e.g. confirmation page or upload progress page). This response code is commonly returned after a PUT or POST request. GET is always used to load this redirected page.
304 Not Modified
There is no need to resend the data after receiving this status code. It is a hidden 301 redirect to a previously visited page. In these cases, either the request method is known to be secure (GET or HEAD) or the request is conditional (using an If-None-Match or If-Modified-Since header). Cache-Control, Content-Location, Date, ETag, Expires, and Vary would have been included in the comparable 200 OK response.
307 Temporary Redirect
Any time you get this status code, know that the requested resource has been temporarily relocated to the URI. Response’s Location field contains the temporary URI. When a request is redirected, only a 307 status code is returned instead than the more generic 302 Found status code. There is no difference in behavior between 302 and 307 for GET requests. Non-GET methods and 302 Found responses are thus unpredictable on the web, while 307 responses are standard.
Use 303 See Other when you want to request that GET be substituted for the original method. This is helpful when responding to a PUT request with a confirmation message rather than the uploaded resources (e.g., “You successfully uploaded XYZ”).
308 – Permanent Redirect
This status code is returned when the requested resource has been permanently relocated to the specified Uniform Resource Identifier (URI). The response’s Location field contains the permanent URI. Both the request method and the request body will be preserved, unlike the case with 301, when the latter is often mistakenly converted to a GET method while the former is lost.
400 codes – Client Errors
400 Bad Request
Client-side errors, such as improperly formatted request syntax, invalid request message framing, or misleading request routing, result in this status code, which indicates that the server is unable to process the request. It is recommended that the customer does not submit this request again unless changes are made.
401 Not Authorized
The request could not be processed because it did not include adequate authentication data to access the requested resource, as shown by this status code. The WWW-Authenticate header attached to this status message specifies how authentication should be performed. It is possible to access the requested resource again by retrying the request and providing authentication information the second time. An authentication is still an option, unlike the 403 status.
402 Payment Required
There is no current plan to implement this client error status code. This was originally designed to work with electronic payment systems and serve as a warning that a request would be delayed until the customer provided payment. There is no agreed-upon definition or context in which it should be used, and so its use varies widely among various entities.
403 No access granted
The server has processed the request but decided not to grant access.
The status code is identical to that of 401 Unauthorized, except in this case, re-authenticating won’t change anything and a second request is unnecessary. Application logic, such as insufficient rights to a resource, is used to permanently deny access. If the server does not wish the reason for the rejection to be hidden from the client, it can use the 403 status code for any request method other than HEAD. The 404 Not Found status code is used if the server is unwilling to provide the requested resource.
404 File or Page Not Found
The server returned an error status code indicating it was unable to find any resources matching the provided Request-URI. Link rot can affect websites with broken links (also known as dead links). There is no word on whether this is a temporary or permanent issue. In contrast, a 410 Gone status should be used rather than a 404 Not Found status if the server is aware that the resource has been deleted permanently. If the server does not want to provide additional information about why the request was denied, or if no alternative response is appropriate, it will often return this status code. By default, a 404 response can be saved in a cache.
405 Prohibited Procedure
The server recognizes the requesting method but cannot fulfill it because it is not compatible with the requested resource, as shown by this status code. The resource at the given Request-URI cannot be accessed through the Request-Line function. Allow header fields MUST be generated by the server and provide a list of accepted methods for the requested resource. The default caching policy applies to a 405 response.
408 Request Timeout
The server has decided to close the connection since the timeout period for the request has expired and the server is no longer willing to keep it open. The client is allowed to resubmit the request at a later date without making any changes. Since 408 indicates that the server has opted to cancel the connection rather than continue waiting, the server should send the “close” Connection header field in the response.
409 Conflict
An incompatibility between the request and the current state of the resource being accessed causes this status code to be returned. This code is permitted when it is thought that the client may be able to resolve the dispute and retry the request. Therefore, the conflict’s origin should be clearly articulated in the body of the response.
A PUT request is where you’ll see this most often. For instance, if the file you’re trying to upload is older than the one already on the server, a 409 response indicates a problem in the version control system. Here, the answer Content-Type dictates the format in which a list of changes between the two versions should be included.
410 Gone
This error number means that the requested resource is permanently unavailable on the server from which it was requested and no alternative address is known. For situations where the server administrator is unsure whether the error is transitory or not, the 404 status code should be utilized.
By informing the client that the resource has been made inaccessible on purpose and that the server’s owners prefer that remote links to that resource be removed, the 410 response is primarily meant to facilitate the process of web maintenance. Limited-time offers and resources belonging to former server employees are particularly vulnerable to this problem. Caching is enabled by default for a 410 answer.
414 URI Too Long
With this status code, the server has decided not to carry out the request because the client-supplied Request-URI is too long.
This could occur if, for example, a client a) incorrectly converted a POST request to a GET request with long query information, b) fell into a redirection loop (for example, a redirected URI prefix that points to a suffix of itself), or c) was attacking the server in an attempt to exploit security vulnerabilities. By default, a 414 answer can be stored in a cache.
415 Incompatible Media Format
An unsupported payload format is the reason the server returned this status code. The request’s Content-Type or Content-Encoding headers, or a visual inspection of the data, could be to blame for the format error.
418 I am a teapot
The server has decided it is a teapot and will never change its mind, as indicated by this status code. Rather than displaying “Out of Coffee,” a combination coffee/tea maker’s response should read “503 Service Unavailable.” This status code was initially defined in RFC 2324, Hyper Text Coffee Pot Control Protocol, as an April Fools’ Day hoax by the Internet Engineering Task Force (IETF) in 1998. The Nginx HTTP server emulates the behavior of the goto directive by returning this code in response to requests that it does not wish to process, such as automated inquiries.
429 Too many requests
The user has exceeded the allowed pace of requests (“rate limitation”), as shown by this status code. Response representations may have an explanation of the error and a Retry-After header specifying the amount of time to elapse before resubmitting the request. Responding to each request with a 429 status code uses resources, therefore it may be more efficient to simply terminate connections or take other measures when a server is under assault or receiving a huge number of requests from a single party.
Server Error Codes
500 Internal Server Error
An unexpected problem stopped the server from completing the request, as indicated by this status code. When the server is unable to determine an appropriate 5xx status code to respond with, it will typically use this error response instead. Error responses, such as the 500 status code, are sometimes logged by server administrators along with additional request details to debug the error and prevent it from occurring again.
501 Not Implemented
The server does not have the requisite capabilities to complete the request, as shown by this status code. The client can learn when to check back to verify if the feature is supported by sending a Retry-After header with this status. Fixing a 501 error is beyond your control and will necessitate the intervention of the service you are trying to reach.
This is the correct response to give when a server does not recognize the requested method and cannot provide support for it on any supported resource. Since only GET and HEAD are mandated by clients, servers should not return 501 for any other method. In cases when the server is aware of the method but chooses not to implement support for it, the 405 Method Not Allowed status code should be returned. Unless otherwise specified via caching headers, a 501 response is cacheable.
502 Bad Gateway
This error code indicates that the gateway or proxy server encountered an unexpected problem while trying to complete the request. To resolve a 502 error, the web server or proxies you are trying to access it through must be updated.
503 Service Unavailable
This status code means that the server is currently overloaded or undergoing maintenance and cannot process any requests. As a short-term fix, this is implemented in the hopes that the problem would go away on its own. Included with this answer ought to be a user-friendly page outlining the issue and an expected time for the recovery of the service in the Retry-After header. The client SHOULD treat the answer as a 500 Internal Server Error if no Retry-After is specified.
504 Gateway Timeout
As a gateway or proxy, the server did not receive a timely response from the upstream server (such as HTTP, FTP, LDAP) or auxiliary server (such as DNS) in order to complete the request. The web server or proxies you’re trying to access through likely need to be updated in order for you to get past a 504 error.
