6.2 Status Codes and Reason Phrases

[Next] [Previous] [Up] [Top] [Full Contents] [Search]

6. Response

6.2 Status Codes and Reason Phrases

The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.

The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:

1xx: Informational - Not used, but reserved for future use
2xx: Success - The action was successfully received, understood, and accepted.
3xx: Redirection - Further action must 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 individual values of the numeric status codes defined for HTTP/1.0, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommended -- they may be replaced by local equivalents without affecting the protocol.

Status-Code	=	"200"   ; OK
	|	"201"   ; Created
	|	"202"   ; Accepted
	|	"203"   ; Provisional Information
	|	"204"   ; No Content
	|	"300"   ; Multiple Choices
	|	"301"   ; Moved Permanently
	|	"302"   ; Moved Temporarily
	|	"303"   ; Method
	|	"304"   ; Not Modified
	|	"400"   ; Bad Request
	|	"401"   ; Unauthorized
	|	"402"   ; Payment Required
	|	"403"   ; Forbidden
	|	"404"   ; Not Found
	|	"405"   ; Method Not Allowed
	|	"406"   ; None Acceptable
	|	"407"   ; Proxy Authentication Required
	|	"408"   ; Request Timeout
	|	"409"   ; Conflict
	|	"410"   ; Gone
	|	"500"   ; Internal Server Error
	|	"501"   ; Not Implemented
	|	"502"   ; Bad Gateway
	|	"503"   ; Service Unavailable
	|	"504"   ; Gateway Timeout
	|	extension-code
extension-code	=	3DIGIT
Reason-Phrase	=	token *( SP token )

HTTP status codes are extensible and should be registered with the IANA. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications are required to understand the class of any status code (as indicated by the first digit) and to treat the response as being equivalent to the x00 status code of that class. For example, if an unknown status code of 421 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents are encouraged to present the entity returned with the response to the user, since that entity is likely to include human-readable information which will explain the unusual status.

Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required in the response.

6.2.1 Successful 2xx

This class of status codes indicates that the client's request was successfully received, understood, and accepted.

200 OK

Following: any method
Required headers: none

The request has been fulfilled and an entity corresponding to the requested resource is being sent in the response. If the HEAD method was used, the response should only contain the Entity-Header information and no Entity-Body.

201 Created

Following: any method that may request a new resource be created
Required headers: URI-header

The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the URI-header field of the response. The origin server is encouraged, but not obliged, to actually create the resource before using this Status-Code. If the action cannot be carried out immediately, or within a clearly defined timeframe, the server should respond with "202 Accepted" instead.

Of the methods defined by this specification, only PUT and POST can create a resource.

202 Accepted

Following: any method
Required headers: none

The request has been accepted for processing, but the processing has not been completed. The request may or may not eventually be acted upon, as it may be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The "202 Accepted" response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response should include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be enacted.

203 Provisional Information

Following: GET, HEAD
Required headers: none

The returned metainformation in the Entity-Header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented may be a subset or superset of the original version. For example, including local annotation information about the resource may result in a superset of the metainformation known by the origin server.

204 No Content

Following: any method
Required headers: none

The server has fulfilled the request but there is no new information to send back. If the client is a user agent, it should not change its document view. This response is primarily intended to allow input for scripts or other actions to take place without causing a change to the user agent's current document view.

6.2.2 Redirection 3xx

This class of status code indicates that further action needs to be taken by the client in order to fulfill the request. The action required can sometimes be carried out by the client without interaction with the user, but it is strongly recommended that this only takes place if the method used in the request is idempotent (GET or HEAD).

300 Multiple Choices

Following: any method
Required headers: none

The requested resource is available at one or more locations and a preferred location could not be determined via content negotiation. Unless it was a HEAD request, the response must include an entity containing a formatted list of resource characteristics and locations from which the user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice may be performed automatically.

301 Moved Permanently

Following: any method
Required headers: URI-header, Location

The requested resource has been assigned a new permanent URI and any future references to this resource must be done using the returned URI. Clients with link editing capabilities are encouraged to automatically relink references to the Request-URI to the new reference returned by the server, where possible.

It is possible for the server to send this status code in response to a request using the PUT, POST, or DELETE methods. However, as this might change the conditions under which the request was issued, the user agent must not automatically redirect the request unless it can be confirmed by the user.

302 Moved Temporarily

Following: any method
Required headers: URI-header, Location

The requested resource resides temporarily under a different URI. Since the redirection may be altered on occasion, the client should on future requests from the user continue to use the original Request-URI and not the URI returned in the URI-header field and Location fields.

303 Method

This code is obsolete.

304 Not Modified

Following: conditional GET
Required headers: none

If the client has performed a conditional GET request and access is allowed, but the document has not been modified since the date and time specified in the If-Modified-Since field, the server shall respond with this status code and not send an Entity-Body to the client. Header fields contained in the response should only include information which is relevant to cache managers and which may have changed independently of the entity's Last-Modified date. Examples of relevant header fields include: Date, Server, and Expires.

6.2.3 Client Error 4xx

The 4xx class of status codes is intended for cases in which the client seems to have erred. If the client has not completed the request when a 4xx code is received, it should immediately cease sending data to the server. Except when responding to a HEAD request, the server is encouraged to include an entity 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.

400 Bad Request

The request had bad syntax or was inherently impossible to be satisfied. The client is discouraged from repeating the request without modifications.

401 Unauthorized

Required headers: WWW-Authenticate

The request requires user authentication. The response must include a WWW-Authenticate header field (Section 6.3.4) containing a challenge applicable to the requested resource. The client may repeat the request with a suitable Authorization header field. HTTP access authentication is explained in Section 10.

402 Payment Required

This code is not currently supported, but is reserved for future use.

403 Forbidden

The request is forbidden because of some reason that remains unknown to the client. Authorization will not help and the request should not be repeated. This status code can be used if the server does not want to make public why the request cannot be fulfilled.

404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. If the server does not wish to make this information available to the client, the status code "403 Forbidden" can be used instead. The "410 Gone" status code should be used if the server knows (through some internally configurable method) that an old resource is permanently unavailable and has no forwarding address.

405 Method Not Allowed

Required headers: Allow

The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response must include an Allow header containing a list of valid method's for the requested resource.

406 None Acceptable

Required headers: Content-*, where applicable to the Request-URI

The server has found a resource matching the Request-URI, but not one that satisfies the conditions identified by the Accept and Accept-Encoding request headers. The response must include (when applicable) the Content-Type, Content-Encoding, and Content-Language of the resource, and is encouraged to include the resource's complete metainformation. No Entity-Body can be included in the response.

407 Proxy Authentication Required

This code is reserved for future use. It is similar to "401 Unauthorized", but indicates that the client must first authenticate itself with the proxy. HTTP/1.0 does not provide a means for proxy authentication -- this feature will be available in future versions.

408 Request Timeout

The client did not produce a request within the time that the server was prepared to wait. The client may repeat the request without modifications at any later time.

409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user may be able to resolve the conflict and resubmit the request. The response body should include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user (or user-agent) to fix the problem; however, that may not be possible and is not required.

Conflicts are most likely to occur in response to a PUT request. If versioning is being used and the entity being PUT includes changes to a resource which conflict with those made by an earlier (third-party) request, the server may use the "409 Conflict" response to indicate that it can't complete the PUT. In this case, the response entity may contain a list of the differences between the two versions.

410 Gone

The requested resource is no longer available at the server and no forwarding address is known. This condition should be considered permanent. Clients with link editing capabilities are encouraged to delete references to the Request-URI (after user approval). If the server does not know (or has no facility to determine) whether or not the condition is permanent, the status code "404 Not Found" can be used instead.

The "410 Gone" 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 event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.

6.2.4 Server Errors 5xx

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. If the client has not completed the request when a 5xx code is received, it should immediately cease sending data to the server. Except when responding to a HEAD request, the server is encouraged to include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These response codes are applicable to any request method and there are no required header fields.

500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.

501 Not Implemented

The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

502 Bad Gateway

The server received an invalid response from the gateway or upstream server it accessed in attempting to complete the request.

503 Service Unavailable

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay may be indicated in a Retry-After header. If no Retry-After is given, the client should handle the response as it would a "500 Internal Server Error".

Note
The presence 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.

504 Gateway Timeout

The server did not receive a timely response from the gateway or upstream server it accessed in attempting to complete the request.

T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen - 12 MAR 95

[Next] [Previous] [Up] [Top] [Full Contents] [Search]

Generated with CERN WebMaker