Any web server will issue HTTP status codes in response to a client’s request. This list shows codes from IETF Request for Comments (RFCs) and some additional commonly used codes. The first digit of the HTTP status code specifies one of five standard classes of responses.
1xx Informational
What do 1xx status codes do? They provide a temporary response. But how do they actually work? 1xx status codes consist of the Status-Line and close with an empty line only, so headers are unnecessary for this type of status code. As HTTP/1.0 provides no definitions for 1xx status codes at all, it’s crucial that servers deliver a 1xx response to a HTTP/1.0 client for investigational reasons only — not under any other circumstances.
The client must be capable of handling one or more 1xx status responses ahead of a standard response, even if that client has no expectations of receiving a 100 continue message. User agents may disregard 1xx status responses safely if they aren’t expecting them.
Proxies, though, need to forward 1xx responses unless there’s a closed connection between the proxy and client or the proxy created the request for the 1xx response itself. For example, if a proxy were to add an ‘expect: 11-continue’ field to the request that has been forwarded, it won’t be required to forward the related 100 (Continue) response (or responses).
100 Continue
The 100 Continue status code indicates that a server has been sent request headers. It also indicates that the relevant client can keep delivering the request body. This applies when a body is necessary (e.g. POST request). For large request bodies, it’s inefficient to deliver it to a server after a request was rejected due to inappropriate headers.
You may ask a server to find out if a request will be accepted exclusively on its headers — send Expect: 100-continue as a header in the initial request. It will continue if the code has been received in response, or it will end if it gets a 417 Expectation Failed response.
101 Switching Protocols
This status code both reveals that a server has been requested to adjust protocols and confirms that this action will be completed. The code acknowledges the request and shows that the server is prepared to follow it, utilizing the Upgrade message header field to alter the application protocol that is being used on the connection.
The server will switch protocols to those stated in the response’s Upgrade header field immediately after finding an empty line ending the 101 Switching Protocols response. Protocols should be adjusted only when there’s a clear benefit, such as switching to an updated HTTP version from older ones. Adjusting to a real-time, synchronous protocol may be an advantage when there’s a need to deliver resources utilizing such features.
102 Processing (WebDAV)
As an interim response, the 102 Processing code notifies the client that the server has accepted the request but has not fulfilled it so far. A 102 Processing code is usually issued only when there’s good reason to expect processing to be a fairly time-consuming process. Servers will issue 102 (Processing) responses when a request will take longer than 20 seconds to run through. They will then deliver the final response upon completing the request.
Methods, primarily those supporting the Depth header, may take time to process. In cases such as these, a client can suspend a connection when awaiting the response. However, when a 102 code is issued, the client will understand to wait while the request is being handled.
2xx Success
This type of status code tells us that the client’s request was received, understood, and processed successfully.
200 OK
A response to say that the request succeeded. The information included along with it will be dependent upon which method the request used, for instance:
- GET an entity that corresponds to the requested resource is sent in the response
- HEAD the entity-header fields that correspond to the requested resources are sent in the response with no message-body
- POST an entity that describes or contains the outcome of the action
- TRACE an entity that contains the request message as received by the end server
201 Created
This means that the request has been completed and a new resource was produced which can be identified using the URI(s) included in the entity that the response relates to, with the most specific URI for the resource given by a Location header field. The response has to include an entity that contains a list of resource characteristics and location(s). A user or user agent can then use this to select the one that’s most appropriate. The entity’s format is defined by whichever media type is presented in the Content-Type header field.
The origin server has to create the resource before it can issue the 201 Created Status Code. If the action can’t be carried out straight away, the server should issue a 202 response (which means Accepted) instead. An ETag response header field can be included in a 201 response to show that the entity tag’s present value for the variant that was requested has just been created.
202 Accepted
The request was accepted for processing, but the processing hasn’t been completed. The request might or might not eventually be acted upon, as it could potentially be disallowed when processing does occur. There is no way to re-send a status code from this kind of unsynchronized operation.
The 202 response is ambivalent on purpose. It’s intended to give a server the chance to look at a request for some other process (maybe a batch-type process that only runs once a day) without any need for the user agent’s server connection to carry on till the procedure has completed. The entity returned with this response has to indicate the current status of the request along with either a link to a status monitor or a rough idea of when the request might be completed.
203 Non-Authoritative Information
The server successfully processed the request, although it’s returning information that might be from a different source. Not found in HTTP/1.0 but found in HTTP/1.1. The returned metainformation in the entity-header isn’t the final set as obtainable from the origin server. Instead, it’s been gleaned from a local or a third-party copy. The set that’s presented CAN be a subset or superset of the original one. For instance, if it includes local annotation information about the resource, this could result in a superset of the metainformation available to the origin server. The use of this response code isn’t a requisite and will only be pertinent when the response would otherwise be 200 (OK).
204 No Content
The request has been completed by the server. It doesn’t need to return an entity-body, but it might want to return updated metainformation though. The response can include new or revised metainformation in the form of entity-headers, and if present these have to be associated with the variant that was requested. When the client is a user agent, it can’t alter its document view from the one that caused the request to be sent.
The main aim of this response is to let input related to actions be entered, without that causing a change to the user agent’s current document view, although any new or updated metainformation has to be applied to the document currently in the user agent’s active view. The 204 response mustn’t contain a message-body, and it’s always ended by an empty line after the header fields.
205 Reset Content
The server has completed the request and the user agent needs to reset the document view that led to it being sent. This response exists so that users can provide input that instigates actions, and then clears the form of that input ready for the next time. The response mustn’t include an entity. This is a little different from a 204 response, where the requester needs to reset the document view themselves.
206 Partial Content
The server has finished processing a partial GET request for the resource. This request needs to have included a Range header field (section 14.35) that specifies the preferred range and was allowed to include an If-Range header field (section 14.27) so the request was made conditional. The following header fields have to be included in the response:
- Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value has to match the actual number of OCTETs transmitted in the message-body.
- Date
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant
If an If-Range request that employed a strong cache validator was what produced the 206 response then it mustn’t contain any other entity-headers. If it was the result of an If-Range request that employed a weak validator, the response mustn’t include other entity-headers; the idea of this is to prevent inconsistencies between updated headers and cached entity-bodies. In other cases, the response needs to contain all of the entity-headers that would have been returned with a 200 (OK) response to an identical request. A cache mustn’t combine a 206 response with other previously cached content if the ETag or Last-Modified headers don’t match exactly (see 13.5.4). A cache that doesn’t support the Content-Range and Range headers mustn’t cache any 206 (Partial) responses.
207 Multi-Status (WebDAV)
This provides status information for numerous independent operations. (Section 11 contains more information on this).
208 Already Reported (WebDAV)
This code can be used within a DAV: propstat response element to avoid numbering the internal members of several bindings to the same collection again and again. For each binding to a collection that falls within the scope of the request, only one is reported with a 200 status, while subsequent DAV: response elements for all supplementary bindings use the 208 status, and no DAV: response elements for their descendants will be included.
Members in a DAV binding will have been counted in a reply prior to this request and aren’t going to be included again.
226 IM Used
The server has completed a GET request for the resource and responded with a representation of the result of one or more instance-manipulations applied to the present instance. The present instance may not be available except by the combination of this response with other preceding or upcoming responses, as might apply for the specific instance-manipulation(s). If this is the case, the headers of the resulting instance come from a combination of the status-226 response headers and the other instances, as stipulated by the rules in section 13.5.3 of the HTTP/1.1 specification.
The request has to have included an A-IM header field that lists a minimum of one instance-manipulation. The response has to include an Etag header field presenting the entity-tag of the present instance.
A response received with a status code of 226 CAN be placed in a cache and deployed when replying to a subsequent request, contingent on the HTTP expiry mechanism and any Cache-Control headers, and on the requirements contained in section 10.6. A response received with a status code of 226 CAN be used by a cache, in conjunction with a cache entry for the base instance, to create a cache entry for the present instance.
3xx Redirection
The 3xx Redirection status code demonstrates that the user agent is required to undertake further action before the request is fulfilled. The user agent may automatically perform the necessary action provided that the HEAD or GET method is utilized in the second request. A client will be required to identify endless redirection loops as these can lead to bidirectional traffic. In the past, the maximum redirections recommended by the specification was five. It’s important, when developing content, to remember that there may still be clients using this limit.
300 Multiple Choices
This status code indicates that the client may follow multiple choices for the resource, each with a distinct location. Agent-driven negotiation information is given so that the user or user agent can choose a representation then redirect the request to the preferred location.
With the exception of HEAD requests, responses should feature an entity offering a list of locations and resource characteristics, from which a user or user agent may pick those most appropriate. The media type given in the header field Content-Type will define the entity format.
It’s possible for the right option to be selected automatically, though that depends on the format and the capabilities of the user agent. Still, this specification sets no standard for this form of automatic selection: when servers have a preferred representation option, they must add the relevant URL to the Location field. User agents can utilize the Location field value to redirect automatically, and this response may be cached when allowed.
301 Moved Permanently
The 301 Moved Permanently status code shows that a new, permanent URL was provided to the requested resource and all references to it in the future should utilize one of the URLs returned. If clients are able to edit links, they should re-link Request-URL references automatically to at least one of those new references that the server has indicated. In some cases, this response can be cached.
In the response, the new permanent URL should be added to the Location field. The request entity must include a concise hypertext note to link the latest URL, unless the HEAD request method was used. If the 301 code is generated by any response apart from the HEAD or GET request, a user agent should not automatically redirect the request, apart from when the relevant user is able to verify it. Otherwise, that may change the conditions leading to the issuance of the request.
However, when a POST request is automatically redirected after a 301 status code is received, some HTTP/1.0 user agents will accidentally switch it to a GET request.
302 Found
Requested resources may be located under a different URL for a time. As there are occasions on which a redirection can be adjusted, the client will need to keep using the Request-URL for future requests. That response will be cached only when it’s shown to be needed by a Cache-Control or Expires header field.
The temporary URL must be provided by the Location field within the response. Apart from when the HEAD request method was utilized, the response entity should contain a brief hypertext note containing a hyperlink to the latest URL. In some cases, the 302 code may be delivered after a request that’s neither HEAD or GET. If so, the user agent should not automatically redirect the request unless the user can confirm it. Otherwise, the conditions that the request was issued under could be changed, too.
Please be aware that with RFC 2068 and RFC 1945, a client is not allowed to adjust the method on the redirected request, though most user agent implementations today view the 302 status code as if it were a 303 response instead. That means they will disregard the initial method of request and execute a GET on the Location field-value. The 307 and 303 status codes were implemented to enable servers to accurately clarify what reaction type they expect of a client.
303 See Other
The request-response has been stored in a different URI and will need a GET method on that resource to recover it. The main reason for this method is to let the output of a POST-activated script send the user agent to a particular resource. The new URI isn’t a stand-in reference for the resource that was originally requested. The 303 response mustn’t be cached, but the response to the second (redirected) request might be cacheable.
The different URI has to be given by the Location field in the response. Except when the request method was HEAD, the response entity has to contain a short hypertext note with a hyperlink to the new URI(s). Note: Many preHTTP/1.1 user agents don’t understand the 303 status. When such clients need to be operated with, the 302 status code can be used instead, because most user agents react to a 302 response as we describe here for 303.
304 Not Modified
Indicates the resource hasn’t been modified because last requested. If a conditional GET request has been performed by the client and access is permitted but the document has not been modified, then the server has to respond with this status code. The 304 Not Modified response mustn’t contain a message-body and is thus always ended by the first empty line after the header fields. The response has to include the following fields in the header:
- Date, except when its omission is required by section 14.18.1
- If a clockless origin server follows these rules, and proxies and clients add their own Date to any response received without one (as previously defined by [ RFC 2068 ], section 14.19), caches will work correctly.
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
- Expires, Cache-Control, and/or Vary, if the field-value differs from the one sent in any earlier response for the same variant.
If a strong cache validator (see section 13.3.3) was used by the conditional GET, the response must not include other entity-headers. Otherwise (such as when conditional GET used a weak validator), the response mustn’t include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
If the 304 response points to an entity that is not currently being cached, then the cache must ignore the response and repeat the request without the condition. If a cache uses a received 304 response to update a cache entry, it will need to update the entry to reflect any new field values given in the answer.
305 Use Proxy
The resource that was requested has to be accessed using the localization field proxy. The field Location provides the proxy URI. It’s anticipated that the recipient will repeat that particular request using the proxy. 305 Reactions only need to be produced by servers of origin. Note: It wasn’t clear from RFC 2068 that 305 was intended to redirect a single request and only be generated by servers of origin. Failure to observe such restrictions has significant consequences for security.
306 (Unused)
The 306 status code isn’t used anymore, and it’s reserved.
307 Temporary Redirect
The requested resource temporarily resides under another URI. Because the redirection may occasionally be altered, the client has to continue to use the Request-URI for future requests. This response is only cachable when indicated by a header field of Cache-Control or Expires. In the response, the temporary URI must be given by the Location field. The response entity has to contain a short hypertext note with a hyperlink to the new URI(s) except when the request method was HEAD because many pre-HTTP/1.1 user agents don’t understand the 307 status. Consequently, the note needs to contain the necessary information for a user to repeat the original request on the new URI. If the status code for 307 is received because of a request other than GET or HEAD, the user agent mustn’t automatically redirect the request except when it can be confirmed by the user, because this might alter the conditions under which the request was issued.
In this case, the request should be repeated with another URI; however, future requests can still use the original URI. In contrast to 302, the request method shouldn’t be altered when reissuing the original request. For instance, a POST request has to be repeated using another POST request.
308 Permanent Redirect (experimental)
This status code says that all subsequent requests should be repeated using another URI. 307 and 308 behave in the same way as 302 and 301 but don’t require an alteration of the HTTP method. So the submission of a form to a permanently redirected resource, for example, can continue as before.
4xx Client Error
The status code type 4xx is intended for instances where the client appears to have made a mistake. The server should include an entity that contains an explanation of the error scenario and whether it’s a temporary or permanent condition, except when responding to a HEAD request. These status codes are applicable to any type of request. User agents have to show any included entity to the user. If the client is sending data, a server implementation using TCP has to ensure that the client acknowledges receipt of the packet(s) that contain(s) the response, before the input connection is closed by the server. If the client continues to send data to the server after closing, the TCP stack of the server will send a reset packet to the client that can erase the unrecognized input buffers of the client before the HTTP application can read and interpret them.
400 Bad Request
Because of bad syntax, the request cannot be fulfilled. The client must not repeat the request without changing it first. A general error would cause an invalid state when the request is fulfilled. Examples of errors include domain validation and missing data.
401 Unauthorized
Like 403 Forbidden, but to be used when it’s perfectly possible to authenticate although this didn’t work or hasn’t been offered yet. The request requires User authentication. The response must include a WWW-Authenticate header field (section 14.47), which has a challenge that applies to the resource being requested. The Customer CAN repeat the request with the relevant Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response tells us that no authorization has been granted for those credentials. If the 401 response includes an identical challenge to the last response, and the user agent has already tried authentication at least once, then the entity given in the response needs to be given to the user, because that entity could include pertinent diagnostic data. HTTP access authentication is covered in “HTTP Authentication: Basic and Digest Access Authentication”.
402 Payment Required
This code has been set aside for use in the future. The initial intention was that this code could be used as part of a form of electronic cash or micropayment program but that outcome hasn’t transpired, so this it isn’t in normal use. Apple’s MobileMe service, though, does produce an example 402 error (“httpStatusCode:402” in the Mac OS X Console log) if the MobileMe account is delinquent.
403 Forbidden
The server has understood the request but is denying it. Unlike a 401 Unauthorized response, authenticating will make no difference and there must be no repeat of the request. If the request method wasn’t HEAD, and the server wishes to say why the request is being denied, the entity’s reason for doing so needs to be outlined. As an alternative, it’s possible to use the status code 404 (Not Found) if the server doesn’t want to that this information to the client.
404 Not Found
Nothing on the server that matches the Request-URI could be found. No indication of whether the condition is permanent or temporary has been given. The status code 410 (Gone) must be used when the server knows that an old tool is indefinitely inaccessible and doesn’t have a forwarding address. This status code is commonly used when the server doesn’t want to reveal exactly why the request was declined, or when there isn’t another answer.
405 Method Not Allowed
For the Resource described by the Request-URI, the method stated in the Request-Line isn’t authorized. The response MUST include an Allow header which contains a list of relevant methods for the resource requested.
406 Not Acceptable
Except when it’s a HEAD request, the response needs to contain an entity with a list of available characteristics of the entity and location(s) from which the user or user agent can select the most suitable one. The format of the entity is dictated by the type of media present in the Content-Type header field. It depends on the user agent’s formatting capabilities as to whether it can automatically select the most appropriate choice. Be aware that the specification doesn’t describe any standards for this kind of automatic selection.
Note: HTTP/1.1 servers may return responses that aren’t acceptable in accordance with the Accept headers sent in the request. Sometimes this can even be the preferred choice to a 406 response being sent. It would be helpful if user agents could pay attention to incoming request headers to check whether they are acceptable or not.
407 Proxy Authentication Required
This code is somewhat like 401 Unauthorized, but it tells us that the client needs to validate itself with the proxy first. The proxy will need to return a Proxy-Authenticate header field (section 14.33) with a challenge that applies to the proxy for the resource requested. The request may be repeated by the client with an appropriate Proxy-Authorization header field (section 14.34). You can find an explanation of HTTP access authentication in “HTTP Authentication: Basic and Digest Access Authentication”.
408 Request Timeout
While it was waiting for the request the server timed out. W3 HTTP specifications state: “The client didn’t produce a request within the time that the server was prepared to wait. The client CAN repeat the request without modifications at any later time.”
409 Conflict
The application couldn’t be performed due to a conflict with the resource’s current state. This code is only permitted in situations where the user is expected to resolve the conflict and to submit the request again. The response body has to include sufficient information to allow the user to identify where the conflict came from. The ideal situation would be for the response entity to offer sufficient information in relation to the problem to allow the user or user agent to resolve it; although that might not be feasible or even necessary. Responding to PUT requests is the most common cause of problems. For instance, when versioning is being used and the thing that’s being PUT includes alterations to a resource that’s in conflict with resources that were created by a prior (third-party) request, the server could use the 409 response to indicate its inability to undertake it. When this happens, the responding entity would probably have a list of the differences between the separate versions in a format that the Content-Type response defines.
410 Gone
The resource that’s been requested can’t be found, there’s no known forwarding address and nor is one likely to be found. If you’re able to edit links, then you should delete any references to this resource. Use a 404 [Not Found] if the server doesn’t know or has no way of finding out if this is a permanent situation. This response can be cashed except when otherwise indicated.
The primary purpose of the 410 response is to help web maintenance. It does this by letting the recipient know that the resource is deliberately unavailable and that the owners of the server want any remote links to it to be taken down. This tends to happen with short-term promotional services and resources and for resources related to people who may have worked with the server but no longer have any involvement. You don’t need to mark every permanently unavailable resource as “gone” or do so indefinitely. That’s entirely up to the server owner.
411 Length Required
The server needs a defined Content-Length before it will accept a request. The client can make the request again so long as it includes a valid Content-Length header field that stipulates in the request message how long the message body is.
412 Precondition Failed
One or more of the request-header fields established a precondition that wasn’t met when the server tested it. This response code can be used by the client to put preconditions on the current resource metainformation (header field data) and by doing so preclude applying the method requested to a resource that isn’t the intended one.
413 Request Entity Too Large
The server is refusing to process a request because the request is larger than the server is willing or able to process. The server CAN close the connection to prevent the client from continuing the request. If the condition is temporary, the server has to include a Retry-After header field to indicate that it is temporary and after what time the client CAN try again.
414 Request-URI Too Long
The URI provided was too long for the server to process. It’s a rare situation that’s only likely to be encountered under certain circumstances, including when the client has converted a POST request to a GET request with excessively long query information, when the client’s become mired in a URI “black hole” of redirection (like when a redirected URI prefix points back to a suffix of itself), or when the server is being attacked by a client that is trying to find a way through the kind of security holes that some servers have using fixed-length buffers that can read and manipulate the Request-URI.
415 Unsupported Media Type
The server won’t process the request since the request entity has been presented in an unsupported format.
416 Requested Range Not Satisfiable
If a request includes a Range request-header field (section 14.35), and none of the range-specifier values in this field are overlapping the current extent of the selected resource, and the request didn’t include an If-Range request-header field, then a server must respond with this status code. (For byte-ranges, this means that the first-byte-pos of all the byte-range-spec values have exceeded the current length of the resource that was selected.) When a byte-range request results in this status code been returned, a Content-Range entity-header field stipulating the present length of the selected resource (see section 14.16) needs to include this in the response. This response mustn’t use the multipart/byte ranges content- type.
417 Expectation Failed
The server can’t meet the requirements of the Expect request-header field, or, if it’s a proxy server it sees a clear indication that the next-hop server couldn’t meet the request.
418 I’m a teapot (RFC 2324)
Actually, an IETF April Fools’ joke that was defined in 1998. The RFC 2324, Hyper Text Coffee Pot Control Protocol wasn’t really intended to be implemented on HTTP servers, but naturally, that hasn’t stopped people from trying. An Nginx HTTP server has used this code to feign goto-like behavior.
420 Enhance Your Calm (Twitter)
The Twitter Search and Trends API returns this when the client is being rate limited. It’s a quote from the movie ‘Demolition Man’ and ‘420’ is probably a nod to the fact that the number’s associated with marijuana. Other services might prefer to use the 429 Too Many Requests response code as an alternative.
422 Unprocessable Entity (WebDAV)
This status code indicates that the server knows what type of content is being requested (which is why a 415(Unsupported Media Type) status code wouldn’t be right), and the request entity syntax is right (which also means a 400 (Bad Request) status code would be equally out of place) but for whatever reason, it still wasn’t able to process the instructions contained in the request. This error condition can sometimes crop up when an XML request body has instructions with the correct syntax, but they contain semantic mistakes.
423 Locked (WebDAV)
The 423 (Locked) status code tells us that the source or destination resource of a method has been locked. This response needs to contain an appropriate precondition or postcondition code, such as ‘lock-token-submitted’ or ‘no-conflicting-lock’.
424 Failed Dependency (WebDAV)
The 424 (Failed Dependency) status code means that the method couldn’t be performed on the resource because the requested action was dependent on another one that failed. For instance, if a command in a PROPPATCH method fails, then, at the very least, the other commands will also fail with 424 (Failed Dependency).
425 Reserved for WebDAV
Slein, J., Whitehead, E.J., et al., “WebDAV Advanced Collections Protocol”, Work in Progress.
426 Upgrade Required
A clear indication of failure is necessary to negotiate reliable, interoperable Upgrade features. The 426 (Upgrade Required) status code lets a server clearly set out the precise protocol extensions a given resource needs to be served with. The client should move to an alternative protocol like TLS/1.0.
428 Precondition Required
The 428 status code shows that the origin server needs the request to be conditional. It’s usually used to avoid the “lost update” problem, which is where a client GETs a resource’s state, adjusts it, and PUTs it back to the server, and while this is happening a third-party has altered the state on the server, which naturally creates a conflict. By insisting that requests should be conditional, the server can ensure that clients are using the right copies. Responses that use this code need to explain how to successfully resubmit it. 428 is an optional status code, which means that clients shouldn’t rely on it to circumvent “lost update” conflicts.
429 Too Many Requests
The 429 status code is saying that the user has sent too many requests during a given period (“rate limiting”).
The response representations need to include details that explain the condition and CAN include a Retry-After header that shows how long to wait before a new request can be made.
When a server is being attacked (or simply being benignly bombarded) with requests from one source, responding to each with a 429 will take up too many valuable resources. Consequently, servers don’t need to use status code 429. When limiting the use of resources, it might be better to something as simple and efficient as dropping connections.
431 Request Header Fields Too Large
This code is saying that the server doesn’t want to process the request because its header fields are too big. The request CAN be submitted again once the size of the request header fields has been reduced.
It can be used when the total set of request header fields are too big, and also when that’s the case with just one header field. In the latter case, the response needs to say which one is too big. Servers don’t necessarily need to use the 431 status code when under attack, as dropping connections is sometimes the more preferable option.
444 No Response (Nginx)
This is an Nginx HTTP server extension that can be useful to deter malware. The server sends no information to the client and shuts down the connection.
449 Retry With (Microsoft)
This is a Microsoft extension that should be retried after performing the most suitable action.
450 Blocked by Windows Parental Controls (Microsoft)
This is a Microsoft extension that appears when Windows Parental Controls have blocked access to a particular webpage.
451 Unavailable For Legal Reasons
As the name suggests, this is used when access to a resource has been denied for legal reasons. Paper ignites at 451°F, which is why this number was chosen. Ray Bradbury’s classic 1953 dystopian novel Fahrenheit 451 explores the society where books are banned and any that are found are destroyed by a dedicated team of “Firemen.”
499 Client Closed Request (Nginx)
An Nginx HTTP server extension. This code appears to log the case when the client closes the connection while the request is being processed by the HTTP server, which means the server can’t send the HTTP header back.
5xx Server Error
When status codes start with “5” this means that the server either knows that it’s made a mistake or it can’t complete the task. Unless it’s responding to a HEAD request, the server has to include an entity that explains what the error situation as, and if it’s permanent or temporary. User agents must show any included entity to the user. These codes will apply to any request method.
500 Internal Server Error
A generic error message that means the server came across a condition that wasn’t expected and it stopped it from performing the request. It’s a generic error message that can cover any situation where the problem is with the server.
501 Not Implemented
The server lacks the functionality needed to perform the request. This response is returned when the server doesn’t understand the requested method or can’t support it for any resource.
502 Bad Gateway
The server was acting as a proxy or a gateway server when it received an invalid response from the upstream server.
503 Service Unavailable
The server can’t deal with the request at the current time because of maintenance or temporary overloading. A Retry-After header can be used to show how long resolving the issue will take. If no Retry-After is given, the client has to act as it would with a 500 response. Be aware that the existence of the 503 status code isn’t meant to suggest that a server has to use it when it’s experiencing overload. It could just refuse the connection.
504 Gateway Timeout
While the server was acting as a gateway or proxy, it didn’t get a timely response from the upstream server that the URI specified (e.g. FTP, HTTP, LDAP) or from a different auxiliary server (e.g. DNS) that it needed to access while it tried to complete the request. Note that some deployed proxies have been known to return 400 or 500 errors when DNS lookups time out.
505 HTTP Version Not Supported
The server either doesn’t support or refuses to support the HTTP protocol version that the request message used. The server indicates that it can’t or won’t fulfil the request using the same major version as the client, as described in section 3.1, except with this error message. The response has to contain an entity that says why that version isn’t supported and what other protocols that server supports.
506 Variant Also Negotiates (Experimental)
A 506 status code means that the server has an internal configuration error: the selected variant resource is set up to take part in transparent content negotiation itself, and so isn’t an appropriate endpoint in the negotiation process.
507 Insufficient Storage (WebDAV)
The 507 (Insufficient Storage) status code tells us that the method couldn’t be conducted on the resource due to the fact that the server can’t store the necessary representation that would allow it to complete the request successfully. This is considered to be a temporary condition. If a user action resulted in the status code that was sent to this request, it shouldn’t be repeated until it’s requested by another user action.
508 Loop Detected (WebDAV)
The 508 (Loop Detected) status code is sent in lieu of code 208, and it’s saying that the server ended an operation because it encountered an infinite loop while it was processing a request. It’s also indicating that the whole operation was a failure.
509 Bandwidth Limit Exceeded (Apache)
Despite the fact that many servers use this status code it isn’t specified in any RFCs.
510 Not Extended
Further extensions to the request are needed so that the server can fulfil it. The policy for accessing the resource wasn’t met in the request. The server should send back all the information necessary so that the client can issue an extended request. It’s beyond the scope of this specification to stipulate how the extensions should pass this information to the client.
If the 510 response contains information that relates to extensions that weren’t present in the original request, the client CAN make the request again if it believes it can fulfill the extension policy by altering the request in accordance with the information given in the 510 response. Alternatively, the client CAN offer any entity mentioned in the 510 response to the user, since that entity may have pertinent diagnostic information to contribute.
511 Network Authentication Required
511 indicates that the client needs to authenticate in order to gain network access.
The response representation has to contain a link to a resource that lets the user send credentials (as it would with an HTML form, for example).
Be aware that the 511 response mustn’t offer a login interface itself or a challenge because (somewhat confusingly) browsers would show the login interface as being associated with the URL that was initially requested. Origin servers should not produce the 511 status. It’s meant to be used by intercepting interposed proxies in order to control network access.
511 status code responses mustn’t be cached.
The client needs to be authenticated in order to receive network access. This code is intended to alleviate difficulties attributable to “captive portals” to software (especially non-browser agents) when that software is expecting a response from the server that a request was made to, not the network infrastructure in between. It isn’t intended to discourage the deployment of captive portals, just to minimize the damage they can cause.
A network operator who wishes to specify some authentication, acceptance of terms or some other user interaction before allowing access to the user will typically do so by identifying clients who haven’t done so (“unknown clients”) via their MAC addresses.
Subsequently, unknown clients will have all traffic blocked unless it’s on TCP port 80, which is routed to an HTTP server (the “login server”) and is specifically there for “logging in” unknown clients, and naturally, traffic to the login server itself.
A response that carries the 511 status code well typically be sent from the origin server shown in the request’s URL, presenting a multitude of security issues. Examples include when an attacking intermediary inserts cookies into the namespace of the original domain, observes cookies or HTTP authentication credentials sent from the user agent.
These risks aren’t confined to the 511 status code though. A captive portal that doesn’t use this status code throws up the same kinds of difficulties.
Also, be aware that captive portals employing this status code on an SSL or TLS connection (commonly, port 443) will produce a certificate error on the client.
598 Network read timeout error
Not specified in any RFCs, but some HTTP proxies use it to indicate a network read timeout behind the proxy to a client that’s in front of the proxy.
599 Network connect timeout error
Not specified in any RFCs, but some HTTP proxies use it to indicate a network connect timeout behind the proxy to a client that’s in front of the proxy.
with
No comment yet, add your voice below!