HTTP/1.1: Status Code Definitions

part ofHypertextTransfer Protocol -- HTTP/1.1
RFC 2616 Fielding, et al. Status Code Definitions
Each Status-Code is described below, including a description of whichmethod(s) it can follow and any metainformation required in theresponse.
Informational 1xx
This class of status code indicates a provisional response,consisting only of the Status-Line and optional headers, and isterminated by an empty line. There are no required headers for thisclass of status code. Since HTTP/1.0 did not define any 1xx statuscodes, servers MUST NOT send a 1xx response to an HTTP/1.0 clientexcept under experimental conditions.
A client MUST be prepared to accept one or more 1xx status responsesprior to a regular response, even if the client does not expect a 100(Continue) status message. Unexpected 1xx status responses MAY beignored by a user agent.
Proxies MUST forward 1xx responses, unless the connection between theproxy and its client has been closed, or unless the proxy itselfrequested the generation of the 1xx response. (For example, if a
proxy adds a "Expect: 100-continue" field when it forwards a request,then it need not forward the corresponding 100 (Continue)response(s).)
100 Continue
The client SHOULD continue with its request. This interim response isused to inform the client that the initial part of the request hasbeen received and has not yet been rejected by the server. The clientSHOULD continue by sending the remainder of the request or, if therequest has already been completed, ignore this response. The serverMUST send a final response after the request has been completed. Seesection8.2.3for detailed discussion of the use and handling of thisstatus code.
101 Switching Protocols
The server understands and is willing to comply with the client'srequest, via the Upgrade message header field (section 14.42), for achange in the application protocol being used on this connection. Theserver will switch protocols to those defined by the response'sUpgrade header field immediately after the empty line whichterminates the 101 response.
The protocol SHOULD be switched only when it is advantageous to doso. For example, switching to a newer version of HTTP is advantageousover older versions, and switching to a real-time, synchronousprotocol might be advantageous when delivering resources that usesuch features.
Successful 2xx
This class of status code indicates that the client's request wassuccessfully received, understood, and accepted.
200 OK
The request has succeeded. The information returned with the responseis dependent on the method used in the request, for example:
GET an entity corresponding to the requested resource is sent inthe response;
HEAD the entity-header fields corresponding to the requestedresource are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by theend server.
201 Created
The request has been fulfilled and resulted in a new resource beingcreated. The newly created resource can be referenced by the URI(s)returned in the entity of the response, with the most specific URIfor the resource given by a Location header field. The responseSHOULD include an entity containing a list of resourcecharacteristics and location(s) from which the user or user agent canchoose the one most appropriate. The entity format is specified bythe media type given in the Content-Type header field. The originserver MUST create the resource before returning the 201 status code.If the action cannot be carried out immediately, the server SHOULDrespond with 202 (Accepted) response instead.
A 201 response MAY contain an ETag response header field indicatingthe current value of the entity tag for the requested variant justcreated, see section14.19.
202 Accepted
The request has been accepted for processing, but the processing hasnot been completed. The request might or might not eventually beacted upon, as it might be disallowed when processing actually takesplace. There is no facility for re-sending a status code from anasynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is toallow a server to accept a request for some other process (perhaps abatch-oriented process that is only run once per day) withoutrequiring that the user agent's connection to the server persistuntil the process is completed. The entity returned with thisresponse SHOULD include an indication of the request's current statusand either a pointer to a status monitor or some estimate of when theuser can expect the request to be fulfilled.
203 Non-Authoritative Information
The returned metainformation in the entity-header is not thedefinitive set as available from the origin server, but is gatheredfrom a local or a third-party copy. The set presented MAY be a subsetor superset of the original version. For example, including localannotation information about the resource might result in a supersetof the metainformation known by the origin server. Use of thisresponse code is not required and is only appropriate when theresponse would otherwise be 200 (OK).
204 No Content
The server has fulfilled the request but does not need to return anentity-body, and might want to return updated metainformation. Theresponse MAY include new or updated metainformation in the form ofentity-headers, which if present SHOULD be associated with therequested variant.
If the client is a user agent, it SHOULD NOT change its document viewfrom that which caused the request to be sent. This response isprimarily intended to allow input for actions to take place withoutcausing a change to the user agent's active document view, althoughany new or updated metainformation SHOULD be applied to the documentcurrently in the user agent's active view.
The 204 response MUST NOT include a message-body, and thus is alwaysterminated by the first empty line after the header fields.
205 Reset Content
The server has fulfilled the request and the user agent SHOULD resetthe document view which caused the request to be sent. This responseis primarily intended to allow input for actions to take place viauser input, followed by a clearing of the form in which the input isgiven so that the user can easily initiate another input action. Theresponse MUST NOT include an entity.
206 Partial Content
The server has fulfilled the partial GET request for the resource.The request MUST have included a Range header field (section 14.35)indicating the desired range, and MAY have included an If-Rangeheader field (section14.27)to make the request conditional.
The response MUST include the following header fields:
- Either a Content-Range header field (section 14.16) indicatingthe range included with this response, or a multipart/byterangesContent-Type including Content-Range fields for each part. If aContent-Length header field is present in the response, itsvalue MUST match the actual number of OCTETs transmitted in themessage-body. - Date - ETag and/or Content-Location, if the header would have been sentin a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value mightdiffer from that sent in any previous response for the samevariant
If the 206 response is the result of an If-Range request that used astrong cache validator (see section 13.3.3), the response SHOULD NOTinclude other entity-headers. If the response is the result of anIf-Range request that used a weak validator, the response MUST NOTinclude other entity-headers; this prevents inconsistencies betweencached entity-bodies and updated headers. Otherwise, the responseMUST include all of the entity-headers that would have been returnedwith a 200 (OK) response to the same request.
A cache MUST NOT combine a 206 response with other previously cachedcontent if the ETag or Last-Modified headers do not match exactly,see13.5.4.
A cache that does not support the Range and Content-Range headersMUST NOT cache 206 (Partial) responses.
Redirection 3xx
This class of status code indicates that further action needs to betaken by the user agent in order to fulfill the request. The actionrequired MAY be carried out by the user agent without interactionwith the user if and only if the method used in the second request isGET or HEAD. A client SHOULD detect infinite redirection loops, sincesuch loops generate network traffic for each redirection.
Note: previous versions of this specification recommended amaximum of five redirections. Content developers should be awarethat there might be clients that implement such a fixedlimitation. 300 Multiple Choices
The requested resource corresponds to any one of a set ofrepresentations, each with its own specific location, and agent-driven negotiation information (section 12) is being provided so thatthe user (or user agent) can select a preferred representation andredirect its request to that location.
Unless it was a HEAD request, the response SHOULD include an entitycontaining a list of resource characteristics and location(s) fromwhich the user or user agent can choose the one most appropriate. Theentity 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 beperformed automatically. However, this specification does not defineany standard for such automatic selection.
If the server has a preferred choice of representation, it SHOULDinclude the specific URI for that representation in the Locationfield; user agents MAY use the Location field value for automaticredirection. This response is cacheable unless indicated otherwise.
301 Moved Permanently
The requested resource has been assigned a new permanent URI and anyfuture references to this resource SHOULD use one of the returnedURIs. Clients with link editing capabilities ought to automaticallyre-link references to the Request-URI to one or more of the newreferences returned by the server, where possible. This response iscacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in theresponse. Unless the request method was HEAD, the entity of theresponse SHOULD contain a short hypertext note with a hyperlink tothe new URI(s).
If the 301 status code is received in response to a request otherthan GET or HEAD, the user agent MUST NOT automatically redirect therequest unless it can be confirmed by the user, since this mightchange the conditions under which the request was issued.
Note: When automatically redirecting a POST request afterreceiving a 301 status code, some existing HTTP/1.0 user agentswill erroneously change it into a GET request. 302 Found
The requested resource resides temporarily under a different URI.Since the redirection might be altered on occasion, the client SHOULDcontinue to use the Request-URI for future requests. This responseis only cacheable if indicated by a Cache-Control or Expires headerfield.
The temporary URI SHOULD be given by the Location field in theresponse. Unless the request method was HEAD, the entity of theresponse SHOULD contain a short hypertext note with a hyperlink tothe new URI(s).
If the 302 status code is received in response to a request otherthan GET or HEAD, the user agent MUST NOT automatically redirect therequest unless it can be confirmed by the user, since this mightchange the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowedto change the method on the redirected request. However, mostexisting user agent implementations treat 302 as if it were a 303response, performing a GET on the Location field-value regardlessof the original request method. The status codes 303 and 307 havebeen added for servers that wish to make unambiguously clear whichkind of reaction is expected of the client. 303 See Other
The response to the request can be found under a different URI andSHOULD be retrieved using a GET method on that resource. This methodexists primarily to allow the output of a POST-activated script toredirect the user agent to a selected resource. The new URI is not asubstitute reference for the originally requested resource. The 303response MUST NOT be cached, but the response to the second(redirected) request might be cacheable.
The different URI SHOULD be given by the Location field in theresponse. Unless the request method was HEAD, the entity of theresponse SHOULD contain a short hypertext note with a hyperlink tothe new URI(s).
Note: Many pre-HTTP/1.1 user agents do not understand the 303status. When interoperability with such clients is a concern, the302 status code may be used instead, since most user agents reactto a 302 response as described here for 303. 304 Not Modified
If the client has performed a conditional GET request and access isallowed, but the document has not been modified, the server SHOULDrespond with this status code. The 304 response MUST NOT contain amessage-body, and thus is always terminated by the first empty lineafter the header fields.
The response MUST include the following header fields:
- Date, unless its omission is required by section 14.18.1
If a clockless origin server obeys these rules, and proxies andclients add their own Date to any response received without one (asalready specified by [RFC 2068], section14.19),caches will operatecorrectly.
- ETag and/or Content-Location, if the header would have been sentin a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value mightdiffer from that sent in any previous response for the samevariant
If the conditional GET used a strong cache validator (see section13.3.3), the response SHOULD NOT include other entity-headers.Otherwise (i.e., the conditional GET used a weak validator), theresponse MUST NOT include other entity-headers; this preventsinconsistencies between cached entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then thecache MUST disregard the response and repeat the request without theconditional.
If a cache uses a received 304 response to update a cache entry, thecache MUST update the entry to reflect any new field values given inthe response.
305 Use Proxy
The requested resource MUST be accessed through the proxy given bythe Location field. The Location field gives the URI of the proxy.The recipient is expected to repeat this single request via theproxy. 305 responses MUST only be generated by origin servers.
Note: RFC 2068 was not clear that 305 was intended to redirect asingle request, and to be generated by origin servers only. Notobserving these limitations has significant security consequences. 306 (Unused)
The 306 status code was used in a previous version of thespecification, is no longer used, and the code is reserved.
307 Temporary Redirect
The requested resource resides temporarily under a different URI.Since the redirection MAY be altered on occasion, the client SHOULDcontinue to use the Request-URI for future requests. This responseis only cacheable if indicated by a Cache-Control or Expires headerfield.
The temporary URI SHOULD be given by the Location field in theresponse. Unless the request method was HEAD, the entity of theresponse SHOULD contain a short hypertext note with a hyperlink tothe new URI(s) , since many pre-HTTP/1.1 user agents do notunderstand the 307 status. Therefore, the note SHOULD contain theinformation necessary for a user to repeat the original request onthe new URI.
If the 307 status code is received in response to a request otherthan GET or HEAD, the user agent MUST NOT automatically redirect therequest unless it can be confirmed by the user, since this mightchange the conditions under which the request was issued.
Client Error 4xx
The 4xx class of status code is intended for cases in which theclient seems to have erred. Except when responding to a HEAD request,the server SHOULD include an entity containing an explanation of theerror situation, and whether it is a temporary or permanentcondition. These status codes are applicable to any request method.User agents SHOULD display any included entity to the user.
If the client is sending data, a server implementation using TCPSHOULD be careful to ensure that the client acknowledges receipt ofthe packet(s) containing the response, before the server closes theinput connection. If the client continues sending data to the serverafter the close, the server's TCP stack will send a reset packet tothe client, which may erase the client's unacknowledged input buffersbefore they can be read and interpreted by the HTTP application.
400 Bad Request
The request could not be understood by the server due to malformedsyntax. The client SHOULD NOT repeat the request withoutmodifications.
401 Unauthorized
The request requires user authentication. The response MUST include aWWW-Authenticate header field (section 14.47) containing a challengeapplicable to the requested resource. The client MAY repeat therequest with a suitable Authorization header field (section14.8).Ifthe request already included Authorization credentials, then the 401response indicates that authorization has been refused for thosecredentials. If the 401 response contains the same challenge as theprior response, and the user agent has already attemptedauthentication at least once, then the user SHOULD be presented theentity that was given in the response, since that entity mightinclude relevant diagnostic information. HTTP access authenticationis explained in "HTTP Authentication: Basic and Digest AccessAuthentication"[43].
402 Payment Required
This code is reserved for future use.
403 Forbidden
The server understood the request, but is refusing to fulfill it.Authorization will not help and the request SHOULD NOT be repeated.If the request method was not HEAD and the server wishes to makepublic why the request has not been fulfilled, it SHOULD describe thereason for the refusal in the entity. If the server does not wish tomake this information available to the client, the status code 404(Not Found) can be used instead.
404 Not Found
The server has not found anything matching the Request-URI. Noindication is given of whether the condition is temporary orpermanent. The 410 (Gone) status code SHOULD be used if the serverknows, through some internally configurable mechanism, that an oldresource is permanently unavailable and has no forwarding address.This status code is commonly used when the server does not wish toreveal exactly why the request has been refused, or when no otherresponse is applicable.
405 Method Not Allowed
The method specified in the Request-Line is not allowed for theresource identified by the Request-URI. The response MUST include anAllow header containing a list of valid methods for the requestedresource.
406 Not Acceptable
The resource identified by the request is only capable of generatingresponse entities which have content characteristics not acceptableaccording to the accept headers sent in the request.
Unless it was a HEAD request, the response SHOULD include an entitycontaining a list of available entity characteristics and location(s)from which the user or user agent can choose the one mostappropriate. The entity format is specified by the media type givenin the Content-Type header field. Depending upon the format and thecapabilities of the user agent, selection of the most appropriatechoice MAY be performed automatically. However, this specificationdoes not define any standard for such automatic selection.
Note: HTTP/1.1 servers are allowed to return responses which arenot acceptable according to the accept headers sent in therequest. In some cases, this may even be preferable to sending a406 response. User agents are encouraged to inspect the headers ofan incoming response to determine if it is acceptable.
If the response could be unacceptable, a user agent SHOULDtemporarily stop receipt of more data and query the user for adecision on further actions.
407 Proxy Authentication Required
This code is similar to 401 (Unauthorized), but indicates that theclient must first authenticate itself with the proxy. The proxy MUSTreturn a Proxy-Authenticate header field (section14.33)containing achallenge applicable to the proxy for the requested resource. Theclient MAY repeat the request with a suitable Proxy-Authorizationheader field (section14.34).HTTP access authentication is explainedin "HTTP Authentication: Basic and Digest Access Authentication"[43].
408 Request Timeout
The client did not produce a request within the time that the serverwas prepared to wait. The client MAY repeat the request withoutmodifications at any later time.
409 Conflict
The request could not be completed due to a conflict with the currentstate of the resource. This code is only allowed in situations whereit is expected that the user might be able to resolve the conflictand 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 theuser or user agent to fix the problem; however, that might not bepossible and is not required.
Conflicts are most likely to occur in response to a PUT request. Forexample, if versioning were being used and the entity being PUTincluded changes to a resource which conflict with those made by anearlier (third-party) request, the server might use the 409 responseto indicate that it can't complete the request. In this case, theresponse entity would likely contain a list of the differencesbetween the two versions in a format defined by the responseContent-Type.
410 Gone
The requested resource is no longer available at the server and noforwarding address is known. This condition is expected to beconsidered permanent. Clients with link editing capabilities SHOULDdelete references to the Request-URI after user approval. If theserver does not know, or has no facility to determine, whether or notthe condition is permanent, the status code 404 (Not Found) SHOULD beused instead. This response is cacheable unless indicated otherwise.
The 410 response is primarily intended to assist the task of webmaintenance by notifying the recipient that the resource isintentionally unavailable and that the server owners desire thatremote links to that resource be removed. Such an event is common forlimited-time, promotional services and for resources belonging toindividuals no longer working at the server's site. It is notnecessary to mark all permanently unavailable resources as "gone" orto keep the mark for any length of time -- that is left to thediscretion of the server owner.
411 Length Required
The server refuses to accept the request without a defined Content-Length. The client MAY repeat the request if it adds a validContent-Length header field containing the length of the message-bodyin the request message.
412 Precondition Failed
The precondition given in one or more of the request-header fieldsevaluated to false when it was tested on the server. This responsecode allows the client to place preconditions on the current resourcemetainformation (header field data) and thus prevent the requestedmethod from being applied to a resource other than the one intended.
413 Request Entity Too Large
The server is refusing to process a request because the requestentity is larger than the server is willing or able to process. Theserver MAY close the connection to prevent the client from continuingthe request.
If the condition is temporary, the server SHOULD include a Retry-After header field to indicate that it is temporary and after whattime the client MAY try again.
414 Request-URI Too Long
The server is refusing to service the request because the Request-URIis longer than the server is willing to interpret. This rarecondition is only likely to occur when a client has improperlyconverted a POST request to a GET request with long queryinformation, when the client has descended into a URI "black hole" ofredirection (e.g., a redirected URI prefix that points to a suffix ofitself), or when the server is under attack by a client attempting toexploit security holes present in some servers using fixed-lengthbuffers for reading or manipulating the Request-URI.
415 Unsupported Media Type
The server is refusing to service the request because the entity ofthe request is in a format not supported by the requested resourcefor the requested method.
416 Requested Range Not Satisfiable
A server SHOULD return a response with this status code if a requestincluded a Range request-header field (section 14.35), and none ofthe range-specifier values in this field overlap the current extentof the selected resource, and the request did not include an If-Rangerequest-header field. (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than thecurrent length of the selected resource.)
When this status code is returned for a byte-range request, theresponse SHOULD include a Content-Range entity-header fieldspecifying the current length of the selected resource (see section14.16).This response MUST NOT use the multipart/byteranges content-type.
417 Expectation Failed
The expectation given in an Expect request-header field (see section14.20) could not be met by this server, or, if the server is a proxy,the server has unambiguous evidence that the request could not be metby the next-hop server.
Server Error 5xx
Response status codes beginning with the digit "5" indicate cases inwhich the server is aware that it has erred or is incapable ofperforming the request. Except when responding to a HEAD request, theserver SHOULD include an entity containing an explanation of theerror situation, and whether it is a temporary or permanentcondition. User agents SHOULD display any included entity to theuser. These response codes are applicable to any request method.
500 Internal Server Error
The server encountered an unexpected condition which prevented itfrom fulfilling the request.
501 Not Implemented
The server does not support the functionality required to fulfill therequest. This is the appropriate response when the server does notrecognize the request method and is not capable of supporting it forany resource.
502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalidresponse from the upstream server it accessed in attempting tofulfill the request.
503 Service Unavailable
The server is currently unable to handle the request due to atemporary overloading or maintenance of the server. The implicationis that this is a temporary condition which will be alleviated aftersome delay. If known, the length of the delay MAY be indicated in aRetry-After header. If no Retry-After is given, the client SHOULDhandle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that aserver must use it when becoming overloaded. Some servers may wishto simply refuse the connection. 504 Gateway Timeout
The server, while acting as a gateway or proxy, did not receive atimely response from the upstream server specified by the URI (e.g.HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it neededto access in attempting to complete the request.
Note: Note to implementors: some deployed proxies are known toreturn 400 or 500 when DNS lookups time out. 505 HTTP Version Not Supported
The server does not support, or refuses to support, the HTTP protocolversion that was used in the request message. The server isindicating that it is unable or unwilling to complete the requestusing the same major version as the client, as described in section3.1,other than with this error message. The response SHOULD containan entity describing why that version is not supported and what otherprotocols are supported by that server.