DEV Community

Cover image for Client Error status codes
Emilie Gervais
Emilie Gervais

Posted on • Updated on

Client Error status codes

Preface: A HTTP status code is issued from the server in response to a client's request made to the server. The five status code response classes are informational, successful, redirection, client error and server error.




Client Error status codes

Client Error status codes indicate that there was a problem with the request. It cannot be fulfilled.

Table Of Contents


400 Bad Request

Definition: The request cannot be understood by the server due to invalid syntax.

400 Bad Request is defined in RFC 7231.


401 Unauthorized

Definition: The request cannot be processed because it lacks valid authentication credentials for the target resource. This status is sent with a WWW-Authenticate header that contains information on how to authorize correctly. This status is similar to 403 Forbidden, but in this case, authentication is possible.

401 Unauthorized is defined in RFC 7235.


402 Payment Required

Definition: The request can not be processed until the client makes a payment. Originally it was created to enable digital cash or (micro) payment systems and would indicate that the requested content is not available until the client makes a payment. However, no standard use convention exists and different entities use it in different contexts. It is a nonstandard client error status response code that is reserved for future use.

402 Payment Required is defined in RFC 7231.


403 Forbidden

Definition: The request was understood by the server but the server refuses to authorize it. This status is similar to 401 Unauthorized except that in this case, re-authenticating will make no difference. The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.

403 Forbidden is defined in RFC 7231.


404 Not Found

Definition: The request is looking for a resource that can't be found by the server but may be available again in the future. Subsequent requests by the client are permissible. Links which lead to a 404 page are often called broken or dead links, and can be subject to link rot. A 404 Not Found status code does not indicate whether the resource is temporarily or permanently missing. But if a resource is permanently removed, a 410 Gone should be used instead of a 404 Not Found status.

404 Not Found is defined in RFC 7231.


405 Method Not Allowed

Definition: The request method is known by the server but is not supported by the target resource. The server MUST generate an Allow header field in a 405 Method Not Allowed response containing a list of the target resource's currently supported methods. For example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource.

405 Method Not Allowed is defined in RFC 7231.


406 Not Acceptable

Definition: The request cannot be fulfilled by the server. The server cannot produce a response matching the list of acceptable values defined in the request's content negotiation headers and is unwilling to supply a default representation. Content negotiation headers include: Accept, Accept-Charset, Accept-Encoding and Accept-Language. 406 Not Acceptable is rarely used: Servers usually ignore the relevant header and serve and actual page to the user. If a server returns such an error status, the body of the message should contain the list of the available representations of the resources, allowing the user to choose among them.

406 Not Acceptable is defined in RFC 7231.


407 Proxy Authentication

Definition: The request has not been applied because it lacks valid authentication credentials for a proxy server that is between the browser and the server that can access the requested resource. The client must first authenticate itself with the proxy. This status is sent with a Proxy-Authenticate header that contains information on how to authorize correctly.

407 Proxy Authentication is defined in RFC 7235.


408 Request Timeout

Definition: The request is taking too long. The server timed out waiting for it or decided to close the connection rather than continue waiting. The client MAY repeat the request without modifications at any later time. In the response, the server should send the close Connection header field. This response is used much more since some browsers, like Chrome, Firefox 27+, and IE9, use HTTP pre-connection mechanisms to speed up surfing.

408 Request Timeout is defined in RFC 7231.


409 Conflict

Definition: The request could not be processed because it is in conflict with the current state of the server. Conflicts are most likely to occur in response to a PUT request. For example, you may get a 409 Conflict response when uploading a file which is older than the one already on the server resulting in a version control conflict.

409 Conflict is defined in RFC 7231.


410 Gone

Definition: The request is looking for a resource that is no longer available and will not be available again. Upon receiving a 410 Gone status code, the client should not request the resource again in the future. If you don't know whether this condition is temporary or permanent, a 404 Not Found status code should be used instead.

410 Gone is defined in RFC 7231.


411 Length Required

Definition: The request did not define Content-Length header, which is required by the requested resource so it cannot be accepted by the server. By specification, when sending data in a series of chunks, the Content-Length header is omitted and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format.

411 Length Required is defined in RFC 7231.


412 Precondition Failed

Definition: The request has been denied access to the target resource. Per example, with conditional requests on methods other than GET and HEAD when the condition defined by the If-Unmodified-Since or If-None-Match headers is not fulfilled. In that case, the request, usually an upload or a modification of a resource, cannot be made and this error response is sent back.

412 Precondition Failed is defined in RFC 7232.


413 Payload Too Large

Definition: The request is larger than the limits defined by the server. The server might close the connection or return a Retry-After header field if the condition is temporary.

413 Payload Too Large is defined in RFC 7231.


414 URI Too Long

Definition: The request is looking for an URI that is longer than what the server is willing to interpret. This is a rare condition that might occur when: A client has improperly converted a POST request to a GET request with more than ≈2 kB of submitted data; a client has descended into a loop of redirection or the server is under attack by a client attempting to exploit potential security holes.

414 URI Too Long is defined in RFC 7231.


415 Unsupported Media Type

Definition: The request is refued by the server because the payload format is unsurpported. The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.

415 Unsupported Media Type is defined in RFC 7231.


416 Range Not Satisfiable

Definition: The request was made for a specific portion of the resource, but the server cannot supply it. The most likely reason is that the document doesn't contain such ranges, or that the Range header value, though syntactically correct, doesn't make sense. The 416 Range Not Satisfiable response message contains a Content-Range indicating an unsatisfied range (that is a '*') followed by a '/' and the current length of the resource. For example: Content-Range: bytes */12777

416 Range Not Satisfiable is defined in RFC 7233.


417 Expectation Failed

Definition: The request has requirements in its Expect header that the server can't meet.

417 Expectation Failed is defined in RFC 7231.


418 I'm a Teapot

Definition: The request wants the server the brew coffee, but the server refuses because it is a teapot. This error is a reference to Hyper Text Coffee Pot Control Protocol which was an April Fools' joke in 1998.

418 I'm a Teapot is defined in RFC 2324.


421 Misdirect Request

Definition: The request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.

421 Misdirect Request is defined in RFC 7540.


422 Unprocessable Entity

Definition: The request is understood by the server but the server is unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed, but semantically erroneous, XML instructions. The client should not repeat this request without modification.

422 Unprocessable Entity is defined in RFC 7918.


423 Locked

Definition: The request is trying to access a locked resource. This response SHOULD contain an appropriate precondition or postcondition code, such as lock-token-submitted or no-conflicting-lock.

423 Locked is defined in RFC 4918.


424 Failed Dependency

Definition: The request failed due to failure of a previous request.

424 Failed Dependency is defined in RFC 4918.


425 Too Early

Definition: The request is considered one that might be replayed and the server is unwilling to risk processing it for security reasons. Replayed requests create the potential for a replay attack.

425 Too Early is defined in RFC 8470.


426 Upgrade Required

Definition: The request cannot be processed using the current protocol, but the server is willing to process it after the client upgrades to a different protocol. The server sends an Upgrade header with this response to indicate the required protocols.

426 Upgrade Required is defined in RFC 7231.


428 Precondition Required

Definition: The request is not conditional and the server requires that it be conditional: A required precondition header, such as If-Match, is missing. When a precondition header is not matching the server side state, the response should be 412 Precondition Failed.

428 Precondition Required is defined in RFC 6585.


429 Too Many Requests

The request is one of too many sent by the user in a given amount of time (\"rate limiting\") Intended for use with rate limiting schemes. A Retry-After header might be included to this response indicating how long to wait before making a new request.

429 Too Many Requests is defined in RFC 6585.


431 Request Header Fields Too Large

Definition: The request's HTTP headers are too long, so the server refuses to process it. 431 can be used when the total size of request headers is too large, or when a single header field is too large. To help those running into this error, indicate which of the two is the problem in the response body — ideally, also include which headers are too large. This lets users attempt to fix the problem, such as by clearing their cookies. Servers will often produce this status if: The Referer URL is too long or if there are too many Cookies sent in the request.

431 Request Header Fields Too Large is defined in RFC 6585.


451 Unavailable For Legal Reasons

Definition: The request is looking for a resource that is not available due to legal reasons. Per example, a web page for which legal action has been issued.

451 Unavailable For Legal Reasons is defined in RFC 7725.




Unofficial and customized non-standard responses defined by server softwares are not included in the list above.

Resources:

Top comments (0)