Types of HTTP Status Codes
Before moving on to 1xx status codes, it is best to know that there are five categories into which we can divide HTTP response codes.
- 1xx Status Codes for information.
- 2xx Status Codes indicate that a request has been processed properly.
- 3xx Status Codes for redirection advise the client that the requested resource is accessible elsewhere on the server.
- 4xx Status Codes for client errors primarily comes from the browser, because the required parameters to visit the requested URL are lacking.
- 5xx Status Codes for Server Errors indicate that the request could not be processed.
Introduction
When a client's request is received with an error, a web server responds with the HTTP status code 4xx. For the purposes of debugging, you can presume that a 4xx code means the browser sent the server the incorrect request, which it was unable to complete. To get the right response, you must verify your browser and send the right request once more.
For instance, using the proper login and password, to access password-protected pages. An explanation for each HTTP 4xx status code is provided below. Keep in mind that these are status codes (and not error codes), which, while usually just providing information, may occasionally signal a mistake.
400 Bad Request Status Code
When the server is unable to understand the request because of an invalid syntax, then we get 400 Bad Request in response.
References for 400 Status Code
- HTTP Status Constant for Python2
httplib.BAD_REQUEST
- HTTP Status Constant for Python3.5+
http.HTTPStatus.BAD_REQUEST
- HTTP Status Constant for Go
http.StatusBadRequest
- HTTP Status Constant for Python3+
http.client.BAD_REQUEST
- HTTP Status Symbol for Rails
bad_request
- HTTP Status Constant for Symfony
Response::HTTP_BAD_REQUEST
401 Unauthorized Status Code
When sending a 401 response, the server MUST provide a WWW-Authenticate header field with at least one challenge that is relevant to the target resource.
The 401 response means that authorization has been denied for the authentication credentials if the request includes them. A new or updated Authorization header field may be included in the request when the user agent repeats it.
The user agent SHOULD show the enclosed representation to the user if the 401 response contains the same challenge as the previous response and at least one authentication attempt has been made by the user agent. This is because the enclosed representation frequently includes pertinent diagnostic data.
References for Code 401
- HTTP Status Constant for Go
http.StatusUnauthorized
- HTTP Status Constant for Python2
httplib.UNAUTHORIZED
- HTTP Status Constant for Python3.5+
http.HTTPStatus.UNAUTHORIZED
- HTTP Status Constant for Symfony
Response::HTTP_UNAUTHORIZED
- HTTP Status Constant for Python3+
http.client.UNAUTHORIZED
- HTTP Status Symbol for Rails
unauthorized
402 Payment Required Status Code
The response with the status code 402 Payment Required is reserved for later use. It was initially developed to be used in digital payment systems, however it is infrequently used and there is no established protocol for doing so.
References for Code 402
- HTTP Status Constant for Python3+
http.client.PAYMENT_REQUIRED
- HTTP Status Constant for Go
http.StatusPaymentRequired
- HTTP Status Symbol for Rails
:payment_required
- HTTP Status Constant for Python2
httplib.PAYMENT_REQUIRED
- HTTP Status Constant for Symfony
Response::HTTP_PAYMENT_REQUIRED
403 Forbidden Status Code
If a server wants to disclose the reason the request was declined, it can do so in the response payload (if any).
The server deems the authentication credentials insufficient to enable access if they were included in the request. The client SHOULD NOT resubmit the request with the same credentials automatically. With changed or alternative credentials, the client MAY resubmit the request. A request, however, may be rejected for factors unrelated to the credentials.
An origin server that wants to “conceal” the fact that a target resource is currently banned MAY instead reply with the response code 404 Not Found.
References for Code 403
- HTTP Status Symbol for Rails
:forbidden
- HTTP Status Constant for Go
http.StatusForbidden
- HTTP Status Constant for Python3+
http.client.FORBIDDEN
- HTTP Status Constant for Symfony
Response::HTTP_FORBIDDEN
- HTTP Status Constant for Python3.5+
http.HTTPStatus.FORBIDDEN
- HTTP Status Constant for Python2
httplib.FORBIDDEN
404 Not Found Status Code
The 410 Gone status code is recommended over 404 if the origin server understands, presumably through some configurable means, that the state is likely to be persistent. A 404 status code does not specify whether this loss of representation is temporary or permanent.
Unless explicitly stated differently by the method description or specific cache controls1, a 404 response is cacheable by default.
References for Code 404
- HTTP Status Constant for Python2
httplib.NOT_FOUND
- HTTP Status Constant for Python3+
http.client.NOT_FOUND
- HTTP Status Symbol for Rails
:not_found
- HTTP Status Constant for Python3.5+
http.HTTPStatus.NOT_FOUND
- HTTP Status Constant for Go
http.StatusNotFound
- HTTP Status Constant for Symfony
Response::HTTP_NOT_FOUND
405 Method Not Allowed Status Code
An allow header field providing a list of the current supported methods for the target resource MUST be generated by the origin server in a 405 response.
A 405 response is cacheable by default, unless the method specification or explicit cache controls specify otherwise.
References for Code 405
- HTTP Status Constant for Python3+
http.client.METHOD_NOT_ALLOWED
- HTTP Status Constant for Go
http.StatusMethodNotAllowed
- HTTP Status Constant for Symfony
Response::HTTP_METHOD_NOT_ALLOWED
- HTTP Status Constant for Python3.5+
http.HTTPStatus.METHOD_NOT_ALLOWED
- HTTP Status Symbol for Rails
:method_not_allowed
- HTTP Status Constant for Python2
httplib.METHOD_NOT_ALLOWED
406 Not Acceptable Status Code
The user or user agent can select the most relevant representation characteristic from a list of available representation characteristics and accompanying resource identifiers that the server SHOULD produce. A user agent MAY choose the best option from that list automatically.
References for Code 406
- HTTP Status Constant for Go
http.StatusNotAcceptable
- HTTP Status Symbol for Rails
:not_acceptable
- HTTP Status Constant for Python3.5+
http.HTTPStatus.NOT_ACCEPTABLE
- HTTP Status Constant for Python2
httplib.NOT_ACCEPTABLE
- HTTP Status Constant for Symfony
Response::HTTP_NOT_ACCEPTABLE
- HTTP Status Constant for Python3+
http.client.NOT_ACCEPTABLE
407 Proxy Authentication Required Status Code
The destination resource requires the proxy to transmit a Proxy-Authenticate header field with a challenge specific to that proxy. The client MAY submit the request again with a modified or new Proxy-Authorization header field.
References for Code 407
- HTTP Status Constant for Go
http.StatusProxyAuthRequired
- HTTP Status Constant for Python3.5+
http.HTTPStatus.PROXY_AUTHENTICATION_REQUIRED
- HTTP Status Symbol for Rails
:proxy_authentication_required
- HTTP Status Constant for Python2
httplib.PROXY_AUTHENTICATION_REQUIRED
- HTTP Status Constant for Symfony
Response::HTTP_PROXY_AUTHENTICATION_REQUIRED
- HTTP Status Constant for Python3+
http.client.PROXY_AUTHENTICATION_REQUIRED
408 Request Timeout Status Code
Since 408 means that the server has decided to stop the connection rather than keep waiting, a server SHOULD supply the “close” connection option in the response. The client MAY make the same request again over a different connection if there is an unfinished request in transit.
Reference for Code 408
- HTTP Status Constant for Python3.5+
http.HTTPStatus.REQUEST_TIMEOUT
- HTTP Status Constant for Symfony
Response::HTTP_REQUEST_TIMEOUT
- HTTP Status Constant for Python2
httplib.REQUEST_TIMEOUT
- HTTP Status Symbol for Rails
:request_timeout
- HTTP Status Constant for Python3+
http.client.REQUEST_TIMEOUT
- HTTP Status Constant for Go
http.StatusRequestTimeout
409 Conflict Status Code
The server SHOULD produce a payload with sufficient details to allow a user to identify the conflict's origin.
The most common time for conflicts to arise is in response to a PUT request. The origin server may use a 409 response to say that it cannot fulfil the request, for instance, if versioning is being utilized and the representation being PUT contains changes to a resource that contradict with those made by an earlier (third-party) request. Based on the revision history, the response representation in this scenario would probably include data that would be relevant for merging the differences.
Reference for Code 409
- HTTP Status Symbol for Rails
:conflict
- HTTP Status Constant for Python3+
http.client.CONFLICT
- HTTP Status Constant for Symfony
Response::HTTP_CONFLICT
- HTTP Status Constant for Go
http.StatusConflict
- HTTP Status Constant for Python3.5+
http.HTTPStatus.CONFLICT
- HTTP Status Constant for Python2
httplib.CONFLICT
410 Gone Status Code
If the origin server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 Not Found ought to be used instead.
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an occurrence is typical for temporary, promotional services as well as for resources belonging to users who are no longer connected to the origin server's website. It is up to the server owner to decide whether to mark all resources that are inaccessible permanently as "gone" or to preserve the mark for an extended period of time.
A 410 answer is cacheable by default, that is, unless the method specification or explicit cache controls specify otherwise.
References for Code 410
- HTTP Status Constant for Python3.5+
http.HTTPStatus.GONE
- HTTP Status Symbol for Rails
:gone
- HTTP Status Constant for Symfony
Response::HTTP_GONE
- HTTP Status Constant for Go
http.StatusGone
- HTTP Status Constant for Python3+
http.client.GONE
- HTTP Status Constant for Python2
httplib.GONE
411 Length Required Status Code
If the client includes a valid Content-Length header field in the request message with the length of the message body, it MAY repeat the request.
References for Code 411
- HTTP Status Symbol for Rails
:length_required
- HTTP Status Constant for Python3+
http.client.LENGTH_REQUIRED
- HTTP Status Constant for Go
http.StatusLengthRequired
- HTTP Status Constant for Symfony
Response::HTTP_LENGTH_REQUIRED
- HTTP Status Constant for Python3.5+
http.HTTPStatus.LENGTH_REQUIRED
- HTTP Status Constant for Python2
httplib.LENGTH_REQUIRED
412 Precondition Failed Status Code
With the help of this response code, the client can impose conditions on the state of the resource at the time of the request (including its representations and metadata) and so prevent the request method from being used if the resource is in an unexpected situation.
References for Code 412
- HTTP Status Constant for Python3+
http.client.PRECONDITION_FAILED
- HTTP Status Constant for Python2
httplib.PRECONDITION_FAILED
- HTTP Status Symbol for Rails
:precondition_failed
- HTTP Status Constant for Python3.5+
http.HTTPStatus.PRECONDITION_FAILED
- HTTP Status Constant for Go
http.StatusPreconditionFailed
- HTTP Status Constant for Symfony
Response::HTTP_PRECONDITION_FAILED
413 Payload Too Large Status Code
To stop the client from submitting another request, the server COULD cut off the connection.
When a condition is transient, the server SHOULD create a Retry-After header field to specify that it is transient and the window of time during which the client MAY attempt a new request.
References for Code 413
- HTTP Status Constant for Python3.5+
http.HTTPStatus.REQUEST_ENTITY_TOO_LARGE
- HTTP Status Constant for Python2
httplib.REQUEST_ENTITY_TOO_LARGE
- HTTP Status Constant for Go
http.StatusRequestEntityTooLarge
- HTTP Status Symbol for Rails
:request_entity_too_large
- HTTP Status Constant for Symfony
Response::HTTP_REQUEST_ENTITY_TOO_LARGE
414 Request-URI Too Long Status Code
This uncommon occurrence is only likely to happen when a client misconverts a POST request to a GET request with extensive query information, when the client falls into a "black hole" of redirection (for example, a redirected URI prefix that points to a suffix of itself), or when the server is being attacked by a client trying to exploit potential security flaws.
A 414 response is cacheable by default, unless the method description or explicit cache controls2 state otherwise.
References for Code 414
- HTTP Status Constant for Go
http.StatusRequestURITooLong
- HTTP Status Constant for Python3+
http.client.REQUEST_URI_TOO_LONG
- HTTP Status Symbol for Rails
:request_uri_too_long
- HTTP Status Constant for Symfony
Response::HTTP_REQUEST_URI_TOO_LONG
- HTTP Status Constant for Python2
httplib.REQUEST_URI_TOO_LONG
- HTTP Status Constant for Python3.5+
http.HTTPStatus.REQUEST_URI_TOO_LONG
415 Unsupported Media Type Status Code
The request's specified Content-Type or Content-Encoding, or a direct inspection of the contents, may have caused the format issue.
References for Code 415
- HTTP Status Constant for Python2
httplib.UNSUPPORTED_MEDIA_TYPE
- HTTP Status Symbol for Rails
:unsupported_media_type
- HTTP Status Constant for Python3.5+
http.HTTPStatus.UNSUPPORTED_MEDIA_TYPE
- HTTP Status Constant for Python3+
http.client.UNSUPPORTED_MEDIA_TYPE
- HTTP Status Constant for Go
http.StatusUnsupportedMediaType
- HTTP Status Constant for Symfony
Response::HTTP_UNSUPPORTED_MEDIA_TYPE
416 Requested Range Not Satisfiable Status Code
When a byte range fails to overlap the current extent, it signifies that all of the byte range specification values' first-byte positions were longer than the current length of the chosen representation. Sender MUST create a Content-Range header field indicating the current length of the chosen representation when this status code is produced in response to a byte-range request2.
Example:
HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022
Note: Since servers are free to ignore Range, many implementations will just send back a 200 OK response that contains the complete specified representation. This is somewhat due to the fact that most clients are ready to finish the work (albeit less effectively) after receiving a 200 OK, and partially due to the possibility that clients won't cease issuing invalid partial requests until they have obtained a complete representation. Therefore, even when it is most appropriate, clients cannot rely on getting a 416 Range Not Satisfiable response.
References for Code 416
- HTTP Status Constant for Symfony
Response::HTTP_REQUESTED_RANGE_NOT_SATISFIABLE
- HTTP Status Constant for Python3+
http.client.REQUESTED_RANGE_NOT_SATISFIABLE
- HTTP Status Symbol for Rails
:requested_range_not_satisfiable
- HTTP Status Constant for Python2
httplib.REQUESTED_RANGE_NOT_SATISFIABLE
- HTTP Status Constant for Python3.5+
http.HTTPStatus.REQUESTED_RANGE_NOT_SATISFIABLE
- HTTP Status Constant for Go
http.StatusRequestedRangeNotSatisfiable
417 Expectation Failed Status Code
The 417 Expectation Failed status code denotes that the server was unable to fulfil the expectation specified in the Expect request-header field.
References for Code 417
- HTTP Status Constant for Python2
httplib.EXPECTATION_FAILED
- HTTP Status Symbol for Rails
:expectation_failed
- HTTP Status Constant for Python3.5+
http.HTTPStatus.EXPECTATION_FAILED
- HTTP Status Constant for Symfony
Response::HTTP_EXPECTATION_FAILED
- HTTP Status Constant for Go
http.StatusExpectationFailed
- HTTP Status Constant for Python3+
http.client.EXPECTATION_FAILED
418 I'm A Teapot Status Code
This status code makes reference to the 1998 April Fool's Day release of the Hyper Text Coffee Pot Control Protocol.
Websites may utilise this status code even if it was originally intended as a joke. For requests they don't want to handle, like automated queries, several websites utilise 418s. The use of 418 is uncommon and not typically regarded as best practise.
References for Code 418
- HTTP Status Constant for Symfony
Response::HTTP_I_AM_A_TEAPOT
- HTTP Status Constant for Go
http.StatusTeapot
421 Misdirected Request Status Code
Regardless of whether the request method is idempotent or not, clients who receive a 421 Misdirected Request response from a server MAY attempt the request via a separate connection. This is conceivable if a connection is reused1 or ALT-SVC is used as an alternate service.
PROXIES MUST NOT produce this status code.
A 421 response is cacheable by default, that is, unless the method specification or explicit cache controls2 specify otherwise.
References for Code 421
- HTTP Status Symbol for Rails
:misdirected_request
422 Unprocessable Entity Status Code
If an XML request body contains well-formed (syntactically valid) but incorrect semantic XML instructions, then this error condition may occur.
References for Code 422
- HTTP Status Symbol for Rails
:unprocessable_entity
- HTTP Status Constant for Symfony
Response::HTTP_UNPROCESSABLE_ENTITY
423 Locked Status Code
A suitable precondition or postcondition code, such as "lock-token-submitted" or "no-conflicting-lock," SHOULD be included in this response.
References for Code 423
- HTTP Status Symbol for Rails
:locked
- HTTP Status Constant for Symfony
Response::HTTP_LOCKED
424 Failed Dependency Status Code
If one of the commands in a PROPPATCH method fails, at the very least the remaining commands will likewise fail with the error code 424 Failed Dependency.
References for Code 424
- HTTP Status Constant for Symfony
Response::HTTP_FAILED_DEPENDENCY
- HTTP Status Symbol for Rails
failed_dependency
- HTTP Status Constant for Python
httplib.FAILED_DEPENDENCY
426 Upgrade Required Status Code
To identify the necessary protocol(s), the server MUST provide an Upgrade header field in a 426 response.
Example:
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain
This service requires use of the HTTP/3.0 protocol.
References for 426 Code
- HTTP Status Symbol for Rails
:upgrade_required
- HTTP Status Constant for Symfony
Response::HTTP_UPGRADE_REQUIRED
428 Precondition Required Status Code
Its typical application is to prevent conflicts caused by "lost updates," in which a client GETs the state of a resource, modifies it, then PUTs it back to the server while another party has changed the state on the server. The server can ensure that clients are using the right copy by demanding conditional requests.
Responses with this status code SHOULD provide instructions on how to correctly resubmit the request. For instance:
HTTP/1.1 428 Precondition Required
Content-Type: text/html
<html>
<head>
<title>Precondition Required</title>
</head>
<body>
<h1>Precondition Required</h1>
<p>This request is required to be conditional; try using "If-Match".</p>
</body>
</html>
References for Code 428
- HTTP Status Constant for Symfony
Response::HTTP_PRECONDITION_REQUIRED
429 Too Many Requests Status Code
A Retry-After header that specifies how long to wait before submitting a new request MAY be included in the response representations, which SHOULD also include information detailing the situation.
Example:
HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600
<html>
<head>
<title>Too Many Requests</title>
</head>
<body>
<h1>Too Many Requests</h1>
<p>I only allow 50 requests per hour to this Web site per
logged in user. Try again soon.</p>
</body>
</html>
Be aware that neither how the origin server recognises the user nor how it counts requests is specified in this standard. For instance, an origin server can impose a limit on the number of requests it accepts based on counts of requests made for each resource, over the entire server, or even across a group of servers. Additionally, a stateful cookie or the user's authentication credentials may be used to identify them.
References for Code 429
- HTTP Status Constant for Symfony
Response::HTTP_TOO_MANY_REQUESTS
431 Request Header Fields Too Large Status Code
It can be applied both when a single header field is at fault and when the overall collection of request header fields is too large. The response representation SHOULD identify which header field was too large in the latter scenario.
For instance:
HTTP/1.1 431 Request Header Fields Too Large
Content-Type: text/html
<html>
<head>
<title>Request Header Fields Too Large</title>
</head>
<body>
<h1>Request Header Fields Too Large</h1>
<p>The "Example" header was too large.</p>
</body>
</html>
References for Code 431
- HTTP Status Constant for Symfony
Response::HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE
444 Connection Closed Without Response Status Code
This status code only appears in the nginx log files and is not visible to clients.
451 Unavailable for Leagal Reasons Status Code
It's possible that the questioned server is not an origin server. ISPs and search engines are often the entities most immediately impacted by this kind of legislative requirement.
An explanation of the specifics of the legal demand, including the party making it, the relevant law or regulation, and the classifications of people and resources it pertains to, SHOULD be included in responses with this status code. For instance:
HTTP/1.1 451 Unavailable For Legal Reasons
Link: <https://spqr.example.org/legislatione>; rel="blocked-by"
Content-Type: text/html
<html>
<head>
<title>Unavailable For Legal Reasons</title>
</head>
<body>
<h1>Unavailable For Legal Reasons</h1>
<p>This request may not be serviced in the Roman Province
of Judea due to the Lex Julia Majestatis, which disallows
access to resources hosted on servers deemed to be
operated by the People's Front of Judea.</p>
</body>
</html>
The usage of the 451 status code does not imply that the resource named in the request is either present or absent. That is to say, even if the legal requirements were lifted, a request for the resource might still be denied.
Keep in mind that clients can frequently still access the blocked resource by employing technical workarounds like a VPN or the Tor network.
A 451 response is cacheable by default, that is, unless the method specification or explicit cache controls specify otherwise.
References for Code 451
- HTTP Status Constant for Symfony
Response::HTTP_UNAVAILABLE_FOR_LEGAL_REASONS
499 Client Closed Request Status Code
A unique status code that Nginx introduced for the situation where a client cuts off the connection while Nginx is handling the request.
Conclusion
A 4xx Client Error status code indicates that the requested website or page was not available or that the request had improper syntax. You should try to avoid these as a website owner because they indicate that your visitors won't find what they're looking for. It could be pages that can't be discovered and are either gone temporarily or permanently. Additionally, providing a poor user experience, it can harm your SEO efforts.