The request has been received but not yet acted upon. It is noncommittal, since there is no way in HTTP to send an asynchronous response indicating the outcome of the request later. The code is intended for cases when another process or server handles the request, or for batch processing.

This error response means that while working as a gateway to get a response
needed to handle the request, the server got an invalid (unacceptable) response.

This response means that the server does not understand the request due to invalid syntax.

This response is sent when a request conflicts with the current state of the server.

This interim response indicates that the request was successful, and the client should continue sending requests or ignore the response if the request is already finished.

The request succeeded, and a new resource was created as a result. This response is typically sent after PUT requests.

This response code indicates that the expectation given in the request’s Expect header could not be met by the server.

The client does not have access to the content, so the server is refusing to give the requested resource.

This response code that the resource requested has been temporarily modified. It will be possible to access changes using the same URI. The client needs to continue using this URI in future requests.

Acting as a gateway or a proxy server, the server didn't get a response from the upstream server in time to finish the current request.

This response is sent when the requested content has been permanently deleted from server.

The HTTP version used in the request is not supported by the server.

The server has encountered a situation it does not know how to handle.

This code was defined in 1998 as one of the traditional IETF April Fools' jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee. This HTTP status is used as an Easter egg in some websites, including Google.com.

Server rejected the request because the Content-Length header is not defined, and the server requires it.

The request method is known to the server, but it has been disabled and cannot be used. The two mandatory methods, GET and HEAD, must never be disabled and should not return this code.

This code means that the URI of the requested resource has been changed.
The new URI may be given in the response.

The code is shown when a request has more than one possible response. The user agent or the user needs to choose one of them. There is no standardized way of choosing one of the responses.

This code means that the information in the response came from a source other that the original server. In other cases the preferred code is 200 OK.

This response is sent when the web server, after performing server-driven content negotiation, doesn’t find any content that conforms to the criteria given by the user agent.

see

#server-driven_content_negotiation

The server cannot find the requested resource. This response code is probably the most well known due to its frequent occurrence on the web.

The request method is not supported by the server and cannot be handled. If the method is known to the server but not applicable to the resource, the response code will be 405 Method Not Allowed.

This code is used for caching purposes. It tells the client that the response has not been modified, so the client can continue using the same cached version of the response.

There is no response body, but there are response headers. The client can use the headrs to update the cached headers that were received earlier.

The request succeeded. The meaning of “success” depends on the HTTP method:

• GET: The resource has been fetched and passed in the message body.
• HEAD: The representation headers are included in the response without any message body.
• POST: The resource describing the result of the server action has been passed in the message body.

This code is used when the client sends a range header to load the content by ranges.

Request entity is larger than the limits defined by the server. The server may close the connection and return the Retry-After header.

This response code is reserved for future use. The initial aim for creating this code was using it for digital payment systems (not used at the moment).
Some platforms use this code in program API when the set limit is exceeded.

This code indicates that the resource requested has been definitively moved to the URL given by the Location: HTTP Response header. This code is similar to 301 Moved Permanently except that the user agent should use the same HTTP method: if POST was used in the original request, then use POST again.

The client has indicated preconditions in headers that the server does not meet.

The server indicates that the client needs to use conditions in header requests (for example, If-Match).

This code indicates that the server has received the request and is processing it, but no response is available yet.

This code is similar to 401 Unauthorized, but the authentication is required for the proxy server.

The range specified in the Range header in the request cannot be fulfilled. The target URI may not contain such ranges.

The server will not necessarily send this code. Instead, it may simply reset the connection.

This response is sent on an idle connection by some servers, even without
any previous request by the client. It means that the server would like to shut down this unused connection. Note that some servers shut down the connection without sending this message.

This code is shown after the successful processing of a request, and it tells the client to reset the view of the document sent in the response.

This response is sent to direct the client to get the requested resource at another URI with a GET request.

The server is not ready to handle the request. Common causes are that the server that is under maintenance or that it is overloaded. Note that together with this response, a user-friendly page explaining the problem should be sent. This response should be used for temporary conditions. The Retry-After HTTP header should, if possible, contain the estimated service recovery time. The webmaster also needs to take care about the caching-related headers that are sent along with this response, as these temporary condition responses should generally not be cached.

This code is shown in response to a request from the client that includes the Upgrade header. It indicates that the server switched to the the protocol specified in the header. This allows you to switch to an incompatible protocol version, so this option is usually not used.

The server sends this response to tell the client to access the requested resource at another URL using the same method as in the previous request.
This code is similar to 302 Found except that in 307 Temporary Redirect the user agent should use the same HTTP method: if POST was used in the original request, then use POST again.

The user has sent too many requests in a given amount of time, which can
indicate, for instance, a DDoS attack attempt. A Retry-After header might be included to this response indicating how long to wait before making a new request.

The client needs to authorize to get the response. This status is similar to 403, but in this case the authentication is possible.

Access to the resource cannot legally be provided (for example, upon request of a government or a copyright holder in case copyright infringement). The error's code is a reference to Ray Bradbury's novel "Fahrenheit 451".

The media format of the requested data is not supported by the server, so the server has rejected the request.

The URI requested by the client is too long for the server to interpret it.