A server responds to a client's browser-side request with a three-digit code called a status code. Using these status codes, the server can communicate quickly and concisely how it handled and responded to a client's request. In addition to these codes, there are also some additional codes used in HTTP applications from IETF Request for Comments (RFCs), other specifications, and some additional codes from other specifications.
In order to maintain an official registry of HTTP status codes, the Internet Assigned Numbers Authority (IANA) is responsible. First digit of a HTTP status code defines the category. Second and third digits define the type of response under that category. HTTP status codes can be classified into five different categories based on the type of response the server communicates to the client:
- 1XX - Informational code: This indicates that the request has been received and understood. In the meantime, the request will continue to be processed. The client is notified to wait for a final response. In this message, only the status line and optional header fields are present, and the message ends with an empty line.
- 2XX - Success code: Indicates the action requested was understood, accepted, and received by the client. This essentially means that the client's request was good, and that the server was able to complete the task completely and successfully.
- 3XX - Redirection code: This code indicates that the client will need to take additional actions in order to complete the request. It is usually a redirection to another URL that is taken as an additional action. URL redirection makes use of many of the status codes in this category.
- 4XX--Client error code indicates that the request cannot be fulfilled because the client is causing an error. It may contain bad syntax or lack authorization, etc. (Except when responding to a HEAD request) the server should include an entity describing the error situation.
- 5XX - Server error code: Servers with this error code cannot perform valid requests. A server should include an entity containing a description of the error situation (except when responding to a HEAD request), and whether it is a temporary or permanent one.
Most Common HTTP Response Status Codes
A.Codes of information
100 Continue
The status code indicates that everything is fine, and the browser should continue with the request or ignore it if it is already complete.
The server informs the client that the initial part of their request has been received and has not yet been rejected. Once the browser receives the response, it should continue sending the remainder of the request or ignore it. A final response must be sent by the server after a request is completed. Before sending the body, the browser must first include Expect: 100-continue in the request header in its initial request.
101 Switching Protocols
Servers with this status code are willing to switch the application protocol in a connection if a browser requests it via an Upgrade request header. Upgrade response headers are also included in the server's response to indicate the protocol change.
If a real-time and synchronous protocol is needed to deliver resources in real-time, it can only be switched when it is advantageous to switch.
103 Early Hints
As the server prepares a response, this status code is used along with the Link header to allow the user-agent (e.g. browser) to preload resources
B.The success codes
OK, 200
Requests with this status code have been successful. HTTP requests have different meanings depending on the method:
GET: The response includes the requested resource along with the message body.
HEAD: The representation headers are transmitted as a response without any message body.
POST: The resource describing the result of the action is transmitted in the response.
TRACE: The response contains the request message as received by the server. If a resource is uploaded for the first time, the status code for success is usually 201 Created, not a 200 OK. 200 responses are cached by default.
201 Created: The result of this request is the creation of a new resource according to the status code. It will be necessary for the server to create the resource before returning the 201. Depending on the request URI, or the location header, the new resource is returned in the body of the message.
202 Accepted: The request for processing has been accepted, but it hasn't been completed or begun. It is possible that the request will not be accepted when processing is actually carried out, as it can be disallowed.
There is no commitment associated with the 202 status. Servers can accept another request for another process (e.g. a batch-oriented process) without requiring the user agent to maintain its connection to the server until the process is complete. Consequently, HTTP cannot send a status code indicating how the request was processed later. Nevertheless, the response will provide a status update, and a time estimate for when the request will be fulfilled or a link to a status monitor.
Non-Authoritative Information 203: It indicates that a transforming proxy has altered the enclosed payload from the origin server's 200 OK response. It's important to note that the metainformation returned in the header is not the definitive set available from the origin server, but gathered from a third-party copy or local copy. 203 responses are cacheable by default.
204 No Content: The client doesn't have to navigate away from its current page when this status code indicates that the request has succeeded, but doesn't need to return a body. 204 responses do not include a body, so the first empty line is always the end of the response.
Despite any new or updated metainformation being applied to the browser's active page, this response will allow input for actions to take place without changing the browser's active page. For instance, when creating a wiki site with "save and continue editing" functionality. In this case a PUT request would be used to save the page, and the 204 response would be sent to indicate that the editor should not be replaced by another page. A 204 response is cacheable by default (an ETag header is included in such a response).
C. Coding for redirection
300 Multiple Choices
There are more than one possible responses to the request indicated by this status code. Users or user-agents should select one of them. If the request was not a HEAD request, the response will provide a list of resource characteristics and locations.
The browser can automatically select the most appropriate choice depending on its format and capabilities. Location field values can be used by a browser for automatic redirection when the server has chosen a preferred representation. In the absence of a standardized way of choosing a response, this response code is rarely used. By default, 300 responses are cacheable.
301 Permanently Moved
A status code of this type indicates that the requested resource has been moved definitively to its new permanent URI. In the response, the Location field provides the permanent URI. Responses with HEAD request methods include a hypertext note with hyperlinks to new URIs. As long as the user confirms that a 301 status code is appropriate, it will not automatically redirect the request unless the request method is GET or HEAD.
For GET or HEAD methods only, a 301 status code should be used, and for POST methods, a 308 Permanent Redirect. 301 responses can by default be cached.
302 Found
There has been a temporary move of the resource requested to the URI indicated by this status code. The Location field in the response provides the temporary URI. An hypertext note with a hyperlink to the new URI(s) will be included in the response if the request method was HEAD. For request methods other than GET or HEAD, a 302 status code will not automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
If the method is changed during a redirected request, it is recommended to use 307 Temporary Redirect instead of 302 as a response. 303 See Other should be used when you want to change the method to GET. This also comes in handy when you want to give a confirmation message as a response to a PUT method, such as: "you successfully uploaded XYZ.". If a Cache-Control header is present or the Expires header is set, a 302 response will be cacheable.
303 See Other
A redirect to a custom page (e.g. confirmation page or upload progress page) is the result of this status code, not the newly uploaded resources. Status codes are typically returned as a result of PUTs and POSTs. Redirected pages are always displayed using the GET method.
304 Not Modified
There is no need to retransmit the requested resources with this status code. Essentially, it is a redirect to a cached resource. Usually, this happens when the request method is safe, e.g. GET or HEAD, or when the request is conditional and includes an If-None-Match header. In a 200 OK response, the headers Cache-Control, Content-Location, Date, ETag, Expires, and Vary would have been included.
307 Temporary Redirect
The resource requested has been temporarily moved to the URI indicated by this status code. A temporary URI is provided in the Location field of the response. 307 and 302 Found differ only in that 307 guarantees that both the method and body will not be changed when the request is redirected. There is no difference between 302 and 307 behavior for GET requests. If a non-GET method is used or a 302 Found is returned, the behavior is unpredictable on the Web, whereas if a 307 is returned, the behavior is predictable.
303 See Other should be used when you want to change the method to GET. Additionally, you can use this to answer a PUT method with a confirmation message instead of uploading the resources (such as "You successfully uploaded XYZ").
308 Permanent redirect
It indicates that the resource requested has been definitively moved to the URI. The Location field in the response contains the permanent URI. The request method and the body will not be altered, whereas 301 may incorrectly sometimes be changed to a GET method.
D.Error codes generated by clients
400 Bad Request
The server cannot process the request because of an error on the client's side, such as malformed request syntax, invalid request message framing, or deceptive request routing. It is recommended that the client not repeat the request unless it has been modified.
401 Unauthorized
Authentication credentials for the target resource are not valid, so the request cannot be applied. The HTTP-Authenticate header contains information about how to authenticate correctly with this status. This status code allows the request to be repeated with authentication to access the target resource. This status is similar to 403, but in this case, authentication is possible.
402 Payment Required
This is a nonstandard client error that will be used in the future. A client would not be able to proceed with the request until he or she made a payment, as it was designed to facilitate digital cash or payment systems. Different organizations use it in different contexts, however, due to the lack of a standard usage convention.
403 Forbidden
Servers with this status code understand requests but refuse to authorize them.
Similar to 401 Unauthorized, re-authenticating will not make a difference in this case, so you don't need to repeat the request. Insufficient rights to a resource can permanently prevent access. For any request methods except HEAD, if the server wants the reason for the refusal to be available to the client, then 403 can be used. It is possible to use 404 Not Found instead if the server refuses to provide this information.
404 Not Found
There is nothing matching the Request-URI on the server, which indicates this status code. A broken or dead link that leads to a 404 page is known as a dead link and can be subject to link rot. In the absence of any indication, it is unclear whether the condition is temporary or permanent. Instead of 404, the server should display 410 Gone if it knows the resource has been permanently removed. In addition, this status code is often used when a server doesn't want to disclose the reason for refusing a request, or when no other response is appropriate. It is by default possible to cache a 404 response.
405 Method Not Allowed
Despite being known by the server, this status code indicates that the requested method is not supported by the target resource. For the resource identified by the Request-URI, the method specified in the Request-Line is not allowed. In order to support requested methods, the server MUST generate an Allow header field. By default, 405 responses can be cached.
408 Request Timeout
Due to the request exceeding the server's tolerance for waiting time, this status code indicates that the server would like to shut down this unused connection. At any time in the future, the client may repeat the request without modification. 408 indicates that the server has decided to close the connection rather than wait on the request, so the server should include the "close" Connection header field in the response.
409 Conflict
A conflict with the target resource prevents the request from being completed. When the client is expected to resolve the conflict and resubmit the request, this code is allowed. As a result, the response body should contain enough information so that the client can identify the conflict's source.
Responses to PUT requests are most likely to result in this. You may receive a 409 response when uploading a file that is older than the one already on the server, resulting in a version control conflict. Depending on the response Content-Type, the response should provide a list of the differences between the two versions.
410 Gone
This status code indicates that access to the target resource is no longer available permanently at the origin server, and there is no forwarding address available. A 404 should be used instead if the server owner is unsure whether the condition is temporary or permanent.
410 responses are primarily intended to assist web maintenance by notifying clients that the resource has been made unavailable and that the server owners wish remote links to the resource removed. These events are common with limited-time promotional services and resources belonging to people no longer working on the server. It is by default possible to cache a 410 response.
414 URI Too Long
A request with this status code will not be processed by the server because the Request-URI provided by the client is too long for the server to handle.
This might occur when a client converts a POST request to a GET request that contains long query information improperly, a) when the client descends into a loop of redirection (for example, a redirected URI prefix pointing to the suffix of itself), or b) when a client attempts to exploit potential security holes on the server. By default, 414 responses can be cached.
415 Unsupported Media Type
Due to the unsupported payload format, the server refuses to accept the request. The problem may be caused by the Content-Type or Content-Encoding of the request, or by inspecting the data directly.
418 I’m a teapot
Due to its permanent status as a teapot, this server refuses to brew coffee. The combined coffee/tea pot that is temporarily out of coffee should instead return 503 Service Unavailable. Hyper Text Coffee Pot Control Protocol, RFC 2324, was defined in 1998 as one of the IETF April Fools' jokes. The Nginx HTTP server uses this code to simulate goto-like behavior in its configuration when it receives requests it does not wish to handle, such as automated queries.
429 Too Many Requests
The user has sent too many requests in a given period of time ("rate limiting"). An explanation of the condition can be included in the response representation, along with a Retry-After header indicating how long to wait before making a new request. It may be more appropriate to just drop connections, or take other measures, when a server is under attack or receiving a huge number of requests from one party.
E.Error codes on the server
500 Internal Server Error
The server encountered an unexpected condition that prevented it from fulfilling the request. Servers use this error response as a generic "catch-all" response when they are unable to find a better 5xx status code. Sometimes, server administrators log error responses like the 500 status code with more details about the request to prevent the error from happening again in the future.
501 Not Implemented
This status code indicates that the server does not support the requested functionality. Alternatively, this status can send a Retry-After header, telling the client to check back when the functionality is supported. If you receive a 501 code, you cannot fix it yourself; the web server must fix it.
This is the appropriate response when the server does not recognize the request method and cannot support it. Only GET and HEAD are required, so they must not return 501. A server that recognizes a method, but does not support it, should respond with 405 Method Not Allowed. By default, 501 responses are cached unless caching headers indicate otherwise.
502 Bad Gateway
During the process of fulfilling a request, the server, while acting as a gateway or proxy, received an invalid response from the upstream server. There is nothing you can do to fix a 502 error, it must be resolved by the web server or proxy server.
503 Service Unavailable
As a result of temporary overloading or maintenance, the server is currently unavailable and cannot handle any requests. We expect that this response will alleviate the problem after some time. In addition to this response, the Retry-After header should include an estimate of how long it will take to recover the service, as well as a user-friendly page that describes the problem. It should be handled as a 500 Internal Server Error response if no Retry-After is specified.
504 Gateway Timeout
In an attempt to fulfill the request, the server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or from some other auxiliary server (e.g. DNS). It is usually not possible to fix a 504 error code, but the server or the proxy you are using needs to fix it.