HTTP status codes are a response that is issued by a server in response to a client’s request for information. This in turn lets the client know if the status of the intended. The first digit of the status specifies one of the five types of responses.
I'm sure you are familiar with the popular error “404 Page not found”. There are many more HTTP status codes that exist. While the list below is a complete list of the official HTTP status codes, there are a few unofficial status codes that are not listed.
HTTP Status Codes are contained within an official registry that is maintained by the Internet Assigned Numbers Authority (IANA).

There are 5 categories of HTTP status codes. The first digit will let you know the type of response. While the last two goes into more detail within that response category.
Indicative of a request that is received and understood, the server issues this response on a provisional basis to let the client know that processing is done. This tells the client to wait for the next step. This message only consists of a status line and optional header fields and ends with an empty line.
The request headers have been received by the server and the client should send the request body should there be one to send. This is useful as sending a large request body after the server has rejected your request due to inappropriate headers would be a waste. If an error code is returned the client should not send the request body. Such errors fall within the 400 status code category, which we will touch on later in this article.
The client has requested the server to switch protocols to which the server has agreed. This means that the server has understood the request. The server will generate an Upgrade header field in the response after the empty line at the end of the 101 response that indicates the protocols that will be immediately switched to.
As a WebDAV request involves file operations it may contain many sub-requests that require a long time to complete. This code lets you know that the server is processing the request that is has received but is unable to provide a response just yet.
This informational response code tells the client that final responses that include header fields are likely to come. This is often used to improve performance by utilizing a link header that contains relevant “preload” information. Allowing the client to start fetching the specified resource.
This category indicates that the server has processed the request and it has been received, understood, and accepted. Essentially it means, the request has been successful.
This status code is the traditional response for a successful HTTP request. The specific response will depend on whether the GET or POST method was used. The response then will either contain an entity corresponding to the request, or the result of the action.
The request has been fulfilled by the server and it has resulted in the creation of a new resource.
The server has accepted the request for processing, but it has not yet been completed.
This is sent from a transforming proxy that is returning a modified version of the 200 OK response from the origin server.
The request was successfully processed by the server, however, no content is being returned.
The request was successfully processed by the server and requests the client to reset its document view, however no content is being returned.
Due to a range header sent by the client only part of the resource is being delivered by the server. This header is used by HTTP clients to enable resuming or splitting a download into multiple simultaneous streams.
This is used when an XML message is sent by the server that contains a number of separate response codes. This depends on the number of sub-requests made.
This is usually included in a 207 Multi-Status code. Indicating that the members of a DAV binding have already been enumerated in a preceding part of the response and will not be included again.
This lets the client know that the request for a resource has been fulfilled by the server. It is a representation of the result of one or more instance-manipulations that are applied to the current instance.
This type of status code indicates that the client must take another action to complete the desired request. It is typically used in URL redirection.
Additional action requiring no user interaction can be carried out by a user agent only if the method used in the second request is GET or HEAD. A user agent may automatically redirect a request. It should also detect and intervene to prevent cyclical redirects.
This indicates to the client that multiple options are available for the user agent to choose from. Typically this choice is done via agent-driven content negotiation.
This informs the client that this and all future request should be directed to a specified URI.
Informs the client to browse another URL. This code has been superseded by 303 and 307.
The requested response can be found under another URI using the GET method. When received in response to a POST/PUT/DELETE, the client should presume that the server has received the data and should issue a new GET request to the specified URI.
This status code is an implicit redirection to an already cached resource. This code tells the client that the requested resource has not been modified and is already present with the client. This code is used when the cached copy of a particular resource that has been requested is up to date with the server.
The resource requested is only available via a proxy, for which the address is provided within the response. Due to security reasons, many browsers do not obey this response code.
This is no longer used, it originally meant each request subsequently should use the proxy that is specified within the 306 response.
The request in this specific case should be repeated with a different URI; however, any future request should use the original URI. This is different than the way it was historically implemented using 302. The request method is not allowed to change when reissuing the original request. For example, a GET request will be repeated as another GET request.
This informs the client that this and all future requests should be directed to a specified URI. The HTTP method is not allowed to change similar to 307, unlike 301 and 302. An example of this would be submitting a form to a 308 resource that can still continue smoothly.
A status code that starts with 4xx is indicative of an error that is caused by the client. Unless responding to a HEAD request, an entity containing an explanation of the error situation should be included by the server. This explanation should include if the error is permanent or temporary. These status codes are applicable to any request method. The browser should display any included entity to the user.
Due to an apparent client error, the server cannot or will not process the request. This might be because of a malformed request syntax, a size too large, invalid request message framing, or deceptive request routing.
This code is specifically to be used when authentication is required by a website and has either failed or yet to be provided. A WWW-Authentication header field containing a challenge applicable to the requested resource must be included in the response. In general 401 means, the user is unauthorized and thus is not allow access to the resource requested.
Currently not implemented and is reserved for future use. Its original intention was to be used as part of some form of payment solution. However, this has yet to be implemented. Some companies use it to indicate specific payment-related errors. Such as when a daily request has been exceeded, when there are insufficient funds, when due to a payment issue a website has been temporarily disabled, or when a payment has been blocked due to a fraudulent nature.
The request was understood by the server and contained valid data, however, the action is being refused by the server. This could be due to several reasons including but not limited to a permissions error or the server trying to perform a prohibited action. Usually, this code is provided when authentication provided but the server does not accept it. Subsequent requests by the client should not be performed.

The most common and most popular error code. It informs the client that the requested resource could not be found by the server. This may be temporary or permanent, thus subsequent requests by the client are allowed.
The method used to request the resource is not supported. An example of this is when a GET request is used but the server requires a POST request instead.
The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request.
This status code is generated when authentication must be done by the client with the proxy first.
When the server times out while waiting for a request it will respond with this error code. This happens when the client does not produce a request within the time frame that the server is willing to wait.
This happens when there is a conflict in the current state of the resource, thus the server is unable to process the request. Such as an edit conflict between multiple simultaneous updates.
This is used when the server would like to instruct and inform the client that the resource requested is no longer available and will never be available again. Once the client receives this response it should purge the resource from its cache. This is often used by search engines. In practice, however, a 404 is used instead.
When a resource that has been requested requires the length of its content to be specified, but the client has not done so, the server will return a 411 error.
One of the preconditions set by the requester in the header field is not met by the server. Thus this error code is returned.
The server is unwilling or able to process the request due to it being too large. This used to be called “Request Entity Too Large”.
This usually happens when too much data is being encoded as a query-string of a GET request. This means that the URI provided in the GET request is too long for the server to process. In such cases, the method of the request should be changed from GET to POST. Previously called “Request-URI Too Long”.
The entity requested has a media type that is unsupported by the server or the resource. Such as when a client tries to upload an image that has the wrong format.
When a server cannot supply the portion of the file requested by the client. Such as if the client requests a part of the file that lies beyond the end of said file.
The status code means the requirements of the Expect request-header field cannot be met by the server.
This code was defined as an April Fools’ joke in 1998 by IETF in RFC 2324. It stands for Hyper Text Coffee Pot Control Protocol, and it's not expected to be used. This code is specified by the RFC to be returned by teapots requested to brew coffee.
A response is not able to be produced because it has been directed at a server that is unable to handle the request.
Due to semantic errors, even though the request is well-formed it is not able to be followed.
This response code is generated when access to the resource is being locked.
Another request which was a dependency has failed which in turn caused this request to fail.
This response code is returned when the server is not willing to risk processing a request that might be replayed.
When this error code is received the client should switch to a different protocol, which is specified in the Upgrade header field.
A specific condition is required from the origin server for the request to be completed. This is intended to prevent the “lost update” problem. This is primarily done to avoid a conflict on the server.
Too many requests have been sent by the client to the server within a specified amount of time. Used primarily with rate-limiting schemes.
If either the individual header field or the header fields collectively are too large, then the server will be unwilling to process the request.
For this HTTP Status Code, the sever is complying with a legal demand to deny access to a particular or set of resources. This happens when the server operator has been presented with either a legal demand or a court order. The number 451 was chosen as a reference to the novel Fahrenheit 451.

This category of error codes occurs when the server fails to fulfill a request sent by a client. Response status codes that start with the digit “5” indicate that the server is aware that it has experienced an error or has failed to perform the request at hand.
Unless responding to a HEAD request, an entity containing an explanation of the error situation should be included by the server. This explanation should include if the error is permanent or temporary. These status codes are applicable to any request method. The browser should display any included entity to the user.
This is a generic error message, it is provided when an unexpected situation was met and there isn't a more suitable message available.
This response is provided when the server either lacks the ability to fulfill the request or it fails to recognize the request method. This more than often implies future availability.
This is usually given when the server is acting as a gateway or proxy and is forwarding an invalid response from an upstream server.
The request cannot be handled by the server, usually due to it being overloaded or down for maintenance. Such an error is generally temporary.
The upstream server did not respond in a timely manner. Therefore the original server or gateway provides this response.
This response code is sent by the server when the HTTP protocol version used within the request is not supported by the server.
The client’s request has caused a closed-loop otherwise known as a circular reference. Which has resulted due to Transparent content negotiation.
The server has run out of storage and cannot store the representation needed to complete the request.
This HTTP Status Code is sent when an infinite loop is detected while processing a request that the client has sent. This status code is sent instead of 208 Already Reported.
The request that the client has sent is not sufficient and a further extension is required before the server can fulfill the request.
Authentication is required by the client to gain network access. Intercepting proxies use this to control access to the network in question. Usually found in captive portals where the user needs to agree to the Terms of Service before being granted full Internet access via public Wi-Fi Hotspots.
Discussion