API Workshop - HTTP Status Codes
Response Status Codes RFC 7231
The status-code element is a three-digit integer code giving the result of the attempt to understand and satisfy the request.
-
HTTP status codes are extensible.
-
HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable.
-
However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class, with the exception that a recipient MUST NOT cache a response with an unrecognized status code.
For example, if an unrecognized status code of 471 is received by a client, the client can assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) status code. The response message will usually contain a representation that explains the status.
The first digit of the status-code defines the class of response.
The last two digits do not have any categorization role.
There are five values for the first digit:
-
1xx (Informational): The request was received, continuing process
-
2xx (Successful): The request was successfully received, understood, and accepted
-
3xx (Redirection): Further action needs to be taken in order to complete the request
-
4xx (Client Error): The request contains bad syntax or cannot be fulfilled
-
5xx (Server Error): The server failed to fulfill an apparently valid request
-
The 1xx (Informational) class of status code indicates an interim response for communicating connection status or request progress prior to completing the requested action and sending a final response.
-
1xx responses are terminated by the first empty line after the status-line (the empty line signaling the end of the header section).
-
Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client.
-
A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one.
-
A user agent MAY ignore unexpected 1xx responses.
-
A proxy MUST forward 1xx responses unless the proxy itself requested the generation of the 1xx response.
-
For example, if a proxy adds an "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).
The server has received the request headers, and that the client should proceed to send the request body.
The requester has asked the server to switch protocols and the server is acknowledging that it will do so.
The server has received and is processing the request, but no response is available yet.
The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.
The standard response for successful HTTP requests.
The request has been fulfilled and a new resource has been created.
The request has been accepted but has not been processed yet. This code does not guarantee that the request will process successfully.
HTTP 1.1. The server successfully processed the request but is returning information from another source.
The server accepted the request but is not returning any content. This is often used as a response to a DELETE request.
Similar to a 204 No Content response but this response requires the requester to reset the document view.
The server is delivering only a portion of the content, as requested by the client via a range header.
The message body that follows is an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.
The members of a DAV binding have already been enumerated in a previous reply to this request, and are not being included again.
The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.
The 3xx (Redirection) class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.
-
If a Location header field (Section 7.1.2) is provided, the user agent MAY automatically redirect its request to the URI referenced by the Location field value, even if the specific status code is not understood.
-
Automatic redirection needs to done with care for methods not known to be safe, as defined in Section 4.2.1, since the user might not wish to redirect an unsafe request.
There are several types of redirects:
-
Redirects that indicate the resource might be available at a different URI, as provided by the Location field, as in the status codes 301 (Moved Permanently), 302 (Found), and 307 (Temporary Redirect).
-
Redirection that offers a choice of matching resources, each capable of representing the original request target, as in the 300 (Multiple Choices) status code.
-
Redirection to a different resource, identified by the Location field, that can represent an indirect response to the request, as in the 303 (See Other) status code.
-
Redirection to a previously cached result, as in the 304 (Not Modified) status code.
There are multiple options that the client may follow.
The resource has been moved and all further requests should reference its new URI.
The HTTP 1.0 specification described this status as "Moved Temporarily", but popular browsers respond to this status similar to behavior intended for 303. The resource can be retrieved by referencing the returned URI.
The resource can be retrieved by following other URI using the GET method. When received in response to a POST, PUT, or DELETE, it can usually be assumed that the server processed the request successfully and is sending the client to an informational endpoint.
The resource has not been modified since the version specified in If-Modified-Since or If-Match headers. The resource will not be returned in response body.
HTTP 1.1. The resource is only available through a proxy and the address is provided in the response.
Deprecated in HTTP 1.1. Used to mean that subsequent requests should be sent using the specified proxy.
HTTP 1.1. The request should be repeated with the URI provided in the response, but future requests should still call the original URI.
Experimental. The request and all future requests should be repeated with the URI provided in the response. The HTTP method is not allowed to be changed in the subsequent request.
This code is used in the Resumable HTTP Requests Proposal to resume aborted PUT or POST requests
-
The 4xx (Client Error) class of status code indicates that the client seems to have erred.
-
Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
-
These status codes are applicable to any request method.
-
User agents SHOULD display any included representation to the user.
The request could not be fulfilled due to the incorrect syntax of the request.
The requester is not authorized to access the resource. This is similar to 403 but is used in cases where authentication is expected but has failed or has not been provided.
Reserved for future use. Some web services use this as an indication that the client has sent an excessive number of requests.
The request was formatted correctly but the server is refusing to supply the requested resource. Unlike 401, authenticating will not make a difference in the server's response.
The resource could not be found. This is often used as a catch-all for all invalid URIs requested of the server.
The resource was requested using a method that is not allowed. For example, requesting a resource via a POST method when the resource only supports the GET method.
The resource is valid, but cannot be provided in a format specified in the Accept headers in the request.
Authentication is required with the proxy before requests can be fulfilled.
The server timed out waiting for a request from the client. The client is allowed to repeat the request.
The request cannot be completed due to a conflict in the request parameters.
The resource is no longer available at the requested URI and no redirection will be given.
The request did not specify the length of its content as required by the resource.
The server does not meet one of the preconditions specified by the client.
The request is larger than what the server is able to process.
The URI provided in the request is too long for the server to process. This is often used when too much data has been encoded into the URI of a GET request and a POST request should be used instead.
The client provided data with a media type that the server does not support.
The client has asked for a portion of the resource but the server cannot supply that portion.
The server cannot meet the requirements of the Expect request-header field.
Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout.
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.
The request was formatted correctly but cannot be processed in its current form. Often used when the specified parameters fail validation errors.
The requested resource was found but has been locked and will not be returned.
The request failed due to a failure of a previous request.
The client should repeat the request using an upgraded protocol such as TLS 1.0.
The origin server requires the request to be conditional.
Additional HTTP Status Codes - RFC 6585
The user has sent too many requests in a given amount of time ("rate limiting").
Additional HTTP Status Codes - RFC 6585
The server is unwilling to process the request because its header fields are too large.
Additional HTTP Status Codes - RFC 6585
A Microsoft extension. Indicates that your session has expired.
Used in Nginx logs to indicate that the server has returned no information to the client and closed the connection (useful as a deterrent for malware).
A Microsoft extension. The request should be retried after performing the appropriate action.
A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.
A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.
The code 451 was chosen as a reference to the 1953 dystopian novel Fahrenheit 451, where books are outlawed.
An HTTP Status Code to Report Legal Obstacles - RFC 7725
Used in Exchange ActiveSync if there either is a more efficient server to use or the server cannot access the users' mailbox.
Nginx internal code similar to 431 but it was introduced earlier in version 0.9.4 (on January 21, 2011).
Nginx internal code used when SSL client certificate error occurred to distinguish it from 4XX in a log and an error page redirection.
Nginx internal code used when client didn't provide certificate to distinguish it from 4XX in a log and an error page redirection.
Nginx internal code used for the plain HTTP requests that are sent to HTTPS port to distinguish it from 4XX in a log and an error page redirection.
Returned by ArcGIS for Server. A code of 498 indicates an expired or otherwise invalid token.
Used in Nginx logs to indicate when the connection has been closed by client while the server is still processing its request, making server unable to send a status code back.
Returned by ArcGIS for Server. A code of 499 indicates that a token is required (if no token was submitted).
-
The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method.
-
Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
-
A user agent SHOULD display any included representation to the user.
These response codes are applicable to any request method.
A generic status for an error in the server itself.
The server cannot respond to the request. This usually implies that the server could possibly support the request in the future — otherwise a 4xx status may be more appropriate.
The server is acting as a proxy and did not receive an acceptable response from the upstream server.
The server is down and is not accepting requests.
The server is acting as a proxy and did not receive a response from the upstream server.
The server does not support the HTTP protocol version specified in the request.
Transparent content negotiation for the request results in a circular reference.
The user or server does not have sufficient storage quota to fulfill the request.
The server detected an infinite loop in the request.
This status code is not specified in any RFCs. Its use is unknown.
Further extensions to the request are necessary for it to be fulfilled.
The client must authenticate with the network before sending requests.
This status code is not specified in any RFC and is returned by certain services, for instance Microsoft Azure and CloudFlare servers: "The 520 error is essentially a "catch-all" response for when the origin server returns something unexpected or something that is not tolerated/interpreted (protocol violation or empty response)."
The origin server has refused the connection from CloudFlare.
CloudFlare could not negotiate a TCP handshake with the origin server.
CloudFlare could not reach the origin server; for example, if the DNS records for the origin server are incorrect.
CloudFlare was able to complete a TCP connection to the origin server, but did not receive a timely HTTP response.
CloudFlare could not negotiate a SSL/TLS handshake with the origin server.
CloudFlare could not validate the SSL/TLS certificate that the origin server presented.
The request timed out or failed after the WAN connection has been established.
| Previous | Next |
|---|---|
| ← HTTP Verbs | HTTP Headers → |