Client Error status codes
Tags: webdev, programming, productivity, softwareengineering
Published: 2020-02-06 21:34:15

---
title: Client Error status codes
published: true
description: listing of client error status codes and their descriptions
tags: webdev, programming, productivity, softwareengineering
series: HTTP Status Code Cheatsheet
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/d1lfy20gk189b6aj0b0l.jpg
---


*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](#bad-request)
  * [401 Unauthorized](#unauthorized)
  * [402 Payment Required](#payment-required)
  * [403 Forbidden](#forbidden)
  * [404 Not Found](#not-found)
  * [405 Method Not Allowed](#method-not-allowed)
  * [406 Not Acceptable](#not-acceptable)
  * [407 Proxy Authentication Required](#proxy-authentication-required)
  * [408 Request Timeout](#request-timeout)
  * [409 Conflict](#conflict)
  * [410 Gone](#gone)
  * [411 Length Required](#length-required)
  * [412 Precondition Failed](#precondition-failed)
  * [413 Payload Too Large](#payload-too-large)
  * [414 URI Too Long](#uri-too-long)
  * [415 Unsupported Media Type](#unsupported-media-type)
  * [416 Range Not Satisfiable](#range-not-satisfiable)
  * [417 Expectation Failed](#expectation-failed)
  * [418 I'm a teapot](#im-a-teapot)
  * [421 Misdirect Request](#misdirect-request)
  * [422 Unprocessable Entity (WebDAV)](#unprocessable-entity)
  * [423 Locked (WebDAV)](#locked)
  * [424 Failed Dependency (WebDAV)](#failed-dependency)
  * [425 Too Early](#too-early)
  * [426 Upgrade Required](#upgrade-required)
  * [428 Precondition Required](#precondition-required)
  * [429 Too Many Requests](#too-many-requests)
  * [431 Request Header Fields Too Large](#request-header-fields-too-large)
  * [451 Unavailable For Legal Reasons](#unavailable-for-legal-reasons)

---
#### `400 Bad Request` <a name="bad-request"></a>

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

`400 Bad Request` is defined in [RFC 7231](https://tools.ietf.org/html/rfc7231#section-6.5.1).

---
#### `401 Unauthorized` <a name="unauthorized"></a>

*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](https://tools.ietf.org/html/rfc7235#section-3.1).

---
#### `402 Payment Required` <a name="payment-required"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.2).

---
#### `403 Forbidden` <a name="forbidden"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.3).

---
#### `404 Not Found` <a name="not-found"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.4).

---
#### `405 Method Not Allowed` <a name="method-not-allowed"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.5).

---
#### `406 Not Acceptable` <a name="not-acceptable"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.6).

---
#### `407 Proxy Authentication` <a name="proxy-authentication"></a>

*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](https://tools.ietf.org/html/rfc7235#section-3.2).

---
#### `408 Request Timeout` <a name="request-timeout"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.7).

---
#### `409 Conflict` <a name="conflict"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.8).

---
#### `410 Gone` <a name="gone"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.9).

---
#### `411 Length Required` <a name="length-required"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.10).

---
#### `412 Precondition Failed` <a name="precondition-failed"></a>

*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](https://tools.ietf.org/html/rfc7232#section-4.2).

---
#### `413 Payload Too Large` <a name="payload-too-large"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.11).

---
#### `414 URI Too Long` <a name="uri-too-long"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.12).

---
#### `415 Unsupported Media Type` <a name="unsupported-media-type"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.13).

---
#### `416 Range Not Satisfiable` <a name="range-not-satisfiable"></a>

*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](https://tools.ietf.org/html/rfc7233#section-4.4).

---
#### `417 Expectation Failed` <a name="expectation-failed"></a>

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

`417 Expectation Failed` is defined in [RFC 7231](https://tools.ietf.org/html/rfc7231#section-6.5.14).

---
#### `418 I'm a Teapot` <a name="im-a-teapot"></a>

*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](https://tools.ietf.org/html/rfc2324#section-2.3.2).

---
#### `421 Misdirect Request` <a name="misdirect-request"></a>

*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](https://tools.ietf.org/html/rfc7540#section-9.1.2).

---
#### `422 Unprocessable Entity` <a name="unprocessable-entity"></a>

*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](https://tools.ietf.org/html/rfc4918#section-11.2).

---
#### `423 Locked` <a name="locked"></a>

*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](https://tools.ietf.org/html/rfc4918#section-11.3).

---
#### `424 Failed Dependency` <a name="failed-dependency"></a>

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

`424 Failed Dependency` is defined in [RFC 4918](https://tools.ietf.org/html/rfc4918#section-11.4).

---
#### `425 Too Early` <a name="too-early"></a>

*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](https://tools.ietf.org/html/rfc8470#section-5.2).

---
#### `426 Upgrade Required` <a name="upgrade-required"></a>

*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](https://tools.ietf.org/html/rfc7231#section-6.5.15).

---
#### `428 Precondition Required` <a name="precondition-required"></a>

*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](https://tools.ietf.org/html/rfc6585#section-3).

---
#### `429 Too Many Requests` <a name="too-many-requests"></a>
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](https://tools.ietf.org/html/rfc6585#section-4).

---
#### `431 Request Header Fields Too Large` <a name="request-header-fields-too-large"></a>

*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](https://tools.ietf.org/html/rfc6585#section-5).

---
#### `451 Unavailable For Legal Reasons` <a name="unavailable-for-legal-reasons"></a>

*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](https://tools.ietf.org/html/rfc7725#section-3).

---

---

---

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

Resources:
- [Hypertext Transfer Protocol (HTTP) Status Code Registry](https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml)
- [Mozilla Developer Network](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status)