HTTP Status Codes
The 1xx set of status codes indicates a conditional response, containing only the Status-Line and web headers that are optional, and this function is terminated by an empty line of code. However, there are no required site headers for this class of 10 status code. Since HTTP/1.0 did not define any 1xx status codes, servers can not send a 1xx response to an HTTP/1.0 client unless it has preexisting experimental conditions for testing purposes.
A client has to be prepared to accept more than one 1xx status responses ahead of a normal response, even if the client did not expect a 100 (also know as continue) status message. For unexpected 1xx status responses, they might be ignored by a user agent.
Proxies are required to forward 1xx client responses, unless the connection between the applicable proxy and the client has been closed, or unless the proxy itself requested the generation of the 1xx response. (As an example, a proxy may add a "Expect: 100-continue" field when it forwards the request, and then it needs not forward the applicable 100 (Continue) response(s).)
The client should continue on with the request being made. This temporary response is used to alert the client that the beginning part of the request has been considered and has not yet been refused by the server. The client should continue the process by sending the remainder of the request or, if the request has already been fully completed, then it will ignore the response. The server is required to send a final response after the request has been finalized.
This code means the server understands and is agrees with the received request, by means of the Upgrade message header field, for an alteration in the application protocol being used on the connection. The server will then switch these protocols to those set forth by the response's Upgrade header area directly after the blank line which it ends the 101 response.
This protocol should be switched only when it is favorable to do. As an example, switching to a more recent version of HTTP is favorable over an old version, and switching to a same-time, synchronous protocol might have its advantages when delivering resources that use these options.
The 2xx class of status codes means that the client's request was well received, fully understood, and approved.
This request has succeeded when receiving this error code. The data returned with this ping-back depends on the method used in the original request.
Here are a few examples that might be used:
GET, which is an entity corresponding to the contacted resource and sent in the response.
HEAD, which is the entity-header fields aligning to the contacted resource and sent in the response without any content in the message's body.
POST, which is an entity detailing or contains the result of the particular action.
TRACE, which is an entity detailing the requested message as received by the end server.
When this request is received, it means it has been completed and has produced in a fresh resource being created. This freshly created resource can be referenced by the URI(s) given back in the entity of the response received, with the most specific URI for the resource given by when is known as a Location header area. This response would be best to include an entity containing a list of resource details and applicable locations from which the user or corresponding user agent can choose the closest one. This special entity layout is directed by the media type received in the Content-Type header area. The beginning server needs to always create the resource before returning this 201 status code. If this action can't be executed at that time, then the server would be best to respond with a 202 (or accepted) response instead.
A 201 response can also contain an ETag response header area, meaning the current value of the entity tag for the requested variable just made.
This code states that the request has been accepted for processing, but the processing has not yet been finalized. This request may or may not be eventually acted upon, as it possibly may be disallowed when the processing actually starts. There is no method for re-sending a status code from an asynchronous option as this.
This 202 response is meaningfully uncommitted. The purpose of the code is to permit a server to accept a request for a different process (such as batch files that run once a day) without demanding that the user's connection to the server remains active until the process is finalized. The entity returned with the response should also include an indicator of the request's current status and either a pointer to a status alert or another quote of when the user can expect the request to be completed.
The returned meta data in this entity-header is not the final set as available from the beginning server, but rather it is pulled from a local or a third party version. This set presented might be a subset or even a superset of the original copy. As an example, including local annotation details about a resource might result in a superset of the meta data known by the original server. The use of this response code is not a requirement and is suited when the response would otherwise be a 200 (OK) code.
This means the server has completed what has been requested of it, but does not need to return an entity-body, and might want to return updated meta data. Such a response might also include new or updated meta data in the form of entity-headers, which if present should be attached with the requested variable.
However, if the client is a user agent, it shouldn't change the document's view from that which caused the request to be sent. The response is mainly intended to allow input for actions to take place without causing alteration to the user agent's active view, however any new or updated meta data would be best applied to the document currently in the user agent's current window.
The 204 response is not permitted to include a message-body, and the results are always ended by the first empty line after the header fields.
This means the server has completed the request and the user agent would be best to reset the document view which caused the request to be sent in the first place. This response is mainly intended to allow input for actions to take place via user input, followed by an emptying of the form in which the input is given so that the user can easily start another input action. The response would be best not to include an entity at this point.
This code states that the server has completed the partial GET request for a resource. The request is required to include a Range header area (section 14.35) stating the desired range, and can optionally have included an If-Range header field to make the request conditional.
The response MUST include the following header fields:
- Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byte-range Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value must 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 this 206 response is the result of an If-Range request that used a strong cache validation system, then the response shouldn't include any other entity-headers. If this response is the result of an If-Range request that used a weak validation system, then the response would be best not to include any other entity-headers; this helps prevent any discrepancies between the cached entity-bodies and the updated headers. The other option is the response is required to include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.
A cache is required not to combine a 206 response with any other previously cached content if the ETag or Last-Modified headers did not match exactly.
A cache that does not support the Range and Content-Range headers is then required not to cache 206 (Partial) responses either.
The 3xx redirection code indicates that further interaction is needed and has to be taken by the user agent in order to complete a request. This action required might be fulfilled by the user agent without any interaction with a user exactly as the method used in the second request is a GET or HEAD. A client is best to detect infinite redirection loops, since such loops generate network traffic for each redirection.
Please Make Note: previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that there might be clients that implement such a fixed limitation in current versions.
The requested resource corresponds to any one of a complete set of representations, and each with its own unique location, and agent-driven negotiation information is being provided so that the user (or user agent) can select an exact representation and redirect its request to that preferred location.
However, if it was a HEAD request, the response most always includes an entity containing a list of resource characteristics and pertinent locations from which the user or user agent can choose from that is the best fitting. This entity format is specified by the media type given in the Content-Type header area. It is important to note that depending upon the format and the ability of he user agent, the selection of the most appropriate choice can be performed with automation. Yet, this specific method does not define any standard for such automatic determination.
If the server has a preferred choice of being displayed, it most always includes the specific URI for that presentation in the Location are; user agents can use the Location area value for automatic redirection. This response is cacheable unless otherwise stated or indicated.
This code means the requested resource has been directed to a new permanent URI and any future inquires to this resource is advisable to use one of the returned URIs. Clients with link editing authorization should automatically re-link any references to the Request-URI to one or more of the new references returned by this server, whenever possible. This response is cacheable unless otherwise indicated.
The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response is best to contain a short hypertext note with a hyperlink to the new URI(s).
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Please Make Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will falsely change it into a GET request.
This codes means the requested resource resides in a temporary location under a different URI. Since the redirection might be modified on occasion, the client for the most part will continue to use the Request-URI for future requests. This type of response is only cacheable if indicated by a Cache-Control or Expires header area.
This temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response usually contains a short hypertext note with a hyperlink to the new URI(s).
If the 302 status code is received in response to a request other than GET or HEAD, the user agent is required not to automatically redirect the request unless it can be confirmed by the user, since this could change the conditions under which the request was originally issued.
Please Make Note: RFC 1945 and RFC 2068 specify that the client is not permitted to change the method on the redirected request. However, most existing user agent installations do treat a 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make it clear without question which kind of reaction is expected of the client.
When receiving a 303 "Other" code, then the response to the request can be found under a different URI and is best received using a GET method on that resource. The method exists as a first source to permit the output of a POST-activated script and redirect the user agent to a predetermined resource. The new URI is not a filler reference for the original requested resource. A 303 response is required not to be cached, but the response to the second (redirected) request can be cacheable.
However, the different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response is best to contain a short hypertext note with a hyperlink to the new URI(s).
Please Make Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.
If a client has executed a conditional GET demand and access is permitted, yet the document has not been altered, then the server is best to respond with the 304 error code. This 304 response is not permitted to contain a message-body, and this means it is always terminated by the first empty line after the header fields.
The response is required to include the following in the header area:
- Date, unless its omission is required
If a "clock-less" source server obeys these rules, and proxies and clients add their own Date to any response received without one, then caches will operate correctly as specified.
- 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
However, if the conditional GET happen to use a strong cache validator, then the response usually does not include other entity-headers. Sometimes (for example, the conditional GET used a weak validator), the response is required not to include other entity-headers. This helps prevent errors between cached entity-bodies and updated headers.
If a 304 response determines an entity not currently cached, then the cache is required to disregard the response and repeat the request without the conditional item.
If a cache uses a received 304 response to update a cache entry, the cache is required to update the entry to reflect any new area values given in the response back.
The requested resource is required to be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request by means of the proxy. 305 responses are required to only be generated by original servers.
Please Make Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not adhering to these requirements can have large security consequences.
The 306 status code was used in a previous version of the specification, is no longer used, and the code is now reserved.
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occurrences, the client is recommended to continue to use the Request-URI for future inquiries. This response is only cacheable if determined by the Cache-Control or Expires header field.
This temporary URI is best to be given by the Location area in the response. Unless the request method was HEAD, the entity of the response usually contains a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not comprehend the 307 status. This being the case, the note usually contains the data necessary for a user to repeat the original request on the new URI.
If the 307 status code is received in response to a demand other than GET or HEAD, the user agent is required not to automatically redirect the inquiry unless it can be determined by the user, since this might change the variables under which the inquiry was issued.
Client Error 4xx
The 4xx status codes class is best fitted for cases in which the client comes across as having erred. Unless when responding to a HEAD request, the server is required to posses an entity containing an break down of the error scenario, and whether it is a temporary or permanent issue. These status codes apply to any request method. User agents are required tp display any included entity to the user.
If the client is sending data, a server implementation using TCP is required to be careful to ensure that the client confirms receipt of the packet(s) included in the response, before the server closes the input connection. If the client maintains sending data to the server after the close, the server's TCP stack will send a reset packet to the client, which may delete the client's unconfimed input buffers before they can be read and interpreted by the HTTP application.
The request could not be understood by the server due to disembodied syntax. The client usually does not repeat the request without modifications.
The request requires user authentication. The response is required to include a WWW-Authenticate header field containing a challenge applicable to the requested resource. The client can repeat the inquiry with a suitable Authorization header area. If the inquiry already includes the Authorization details, then the 401 reply determines that authorization has been rejected for those credentials. If the 401 inquiry contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user is required to be presented the entity that was given in the response, since that entity might include relevant diagnostic data.
This code is not currently in use and is reserved.
This 403 Forbidden code means the server processed the request, but is refusing to answer it. Authorization will not help and the request is best not to be repeated. If the inquiry method was not HEAD and the server wishes to make public why the request has not been fulfilled, it most likely will describe the reason for the refusal in the entity. If the server does not wish to make this data available to the client, the status code 404 (Not Found) can be used in lieu of.
This code states that the server has not discovered anything matching the Request-URI. No indication is given of whether the variable is temporary or permanent. The 410 (Gone) status code most likely will be used if the server knows, through some internally edited mechanism, that an old resource is permanently not available and has no forwarding address. This status code is mostly used when the server does not wish to expose the exact means as to why the request has been refused, or when no other response is available.
The code is delivered when the method specified in the Request-Line is not permitted for the resource discovered by the Request-URI. The response is required to include an Allow header pertaining a list of valid methods for the requested resource.
This resource code is used to identify by the request and is only capable of generating response submissions which have content characteristics that do not meet requirements according to the accept headers sent in the request.
Unless it was a HEAD request, the response most likely will include an entity containing a list of readily available entities characters and location(s) from where the user or user agent can select the one most fitting for use. The entity format is selected by the media type given in the Content-Type header field. However, depending upon the layout and the abilities of the user agent, selection of the best fitting choice can be performed automatically. However, this specification does not define any standard for such automatic selection.
Please Make Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.
If the response could be not approved, a user agent will most likely fill a temporary stop receipt of more data and request the user for a confirmation of further action needed.
The 407 Proxy Authentication Required code is very similar to a 401 (Unauthorized). It determines that the client must first confirm itself with the proxy. The proxy then is required to return a Proxy-Authenticate header field that contains a challenge applicable to the proxy for the requested information. The client can then repeat the inquiry with a suitable Proxy-Authorization header area.
This code means that the client did not provide an inquiry within the allotted time that a server was ready to wait. The client can then repeat the request without alterations at any later time.
This code means the request could not be fulfilled due to an error with the current state of the resource. This code is only permitted in situations where it is agreed that the user might be able to resolve the issue and submit the request again. The response body would be best to include enough data for the user to be familiar with the source of the issue. It would be best if the response entity would also include enough details for the user or user agent to repair the problem; yet, this scenario might not be possible and is not required to move past.
Issues are most likely to happen in response to a PUT inquiry. As an example, if version determination was being used and the entity being PUT included alterations to a resource which issue with those made by a previous (third-party) inquiry, then the server may use the 409 response to determine that it can not fulfill the request. In this case, the response entity would most likely include a list of the differences between the two versions in a format set forth by the response Content-Type.
When receiving this code, it means the requested resource is no longer available at the server and no forwarding address is known. This outcome is expected to be considered permanent. Clients with link editing capabilities find it best to delete any references to the Request-URI after user approval. If the server does not know, or has no ability to confirm whether or not the situation is permanent, the status code 404 (Not Found) is best to be used in lieu. This response is cacheable unless determined by other means.
The 410 response is mainly focused to assist the task of web server repair or maintenance by notifying the recipient that the resource is not available and the responsible party is aware and that the server owners desire that remote links to that resource be replaced or removed. Events like this are common for promotional campaigns and for resources belonging to those no longer working at the server's site. It is not necessary to acknowledge all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the option of the server owner.
The server denies to accept the request without a specified Content- Length. The client can repeat the request if it adds a valid Content-Length header area containing the length of the message-body in the requested message.
This code sets preconditions given in one or more of the request-header areas determined to be false when it was tested on the server. The response code of this nature allows the client to place preconditions on the current resource meta data and thus stop the requested method from being entered onto a resource other than the one intended for receipt.
The server is denying to move forward on a request because the request entity is larger than the server is willing or able to process. The server cam close the connection to stop the client from continuing the request.
If the condition is temporary, the server usually includes a Retry- After the header field to determine that it is temporary and after what time the client cam try again.
The server is denying to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or altering the Request-URI.
The server is denying to service the inquiry because the entity of the request is in a layout not supported by the requested resource for the chosen method.
With the 416 Requested Range Not Satisfiable error code, the server most likely will return a response with this status code if a request included a Range request-header field, and none of the range-specifier values in this field overlap the current extent of the selected item, and the inquiry did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were larger than the current length of the selected resource.)
When this status code is returned for a byte-range inquiry, the response most likely will include a Content-Range entity-header field declaring the current length of the selected resource. This response is required not to use the multipart/byteranges content- type.
This code means the expectation given in an Expect request-header field could not be determined by this server, or, if the server is a proxy, the server has enough evidence that the request could not be met by the next-hop server.
Server Error 5xx
This code shows a response status code beginning with the digit "5" to indicate in cases where the server is familiar that an error has happened, or is not capable of performing another request. Except when answering a HEAD request, the server will most likely include an entity that contains a description of the error situation, and whether it is a temporary or permanent condition. User agents will most likely display any included entity to the user. These response codes are applicable to any request method.
This code states that the server encountered an unexpected situation which prevented it from fulfilling the request.
The server does not support the ability required to fulfill the request. This is the most appropriate response when the server is not familiar with the request method and is not capable of supporting it for any resource.
This code is received when the server, while serving as a gateway or proxy, received a non-valid response from the upstream server it accessed in attempting to fulfill the inquiry.
The server is currently unable to process a request due to a temporary server overloading or maintenance situation. The assumption is that this is a temporary condition which will be alleviated after short time delay. The length of the delay can be indicated in a Retry-After header. If no Retry-After is given, the client will most likely handle the response as it would for a 500 response.
Please Make Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection.
When the 504 Gateway Timeout server code is received while acting as a gateway or proxy, it means that it did not receive an adequate response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (like DNS) that it needed to access in order to complete the request.
Please Make Note: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.
This means the server does not support, or will not support, the HTTP protocol version that was used in the request. The server is also indicating that it is unable or unwilling to complete the transaction using the same major version as the client requesting it other than with this error message. The response will most likely contain an entity describing why that version is not supported and what other protocols are supported by the server.