Status Code Definitions
200 OK
The request has succeeded. The information returned with the response is dependent on the
method used in the request, for example:
GET an entity corresponding to the requested resource is sent in the response;
HEAD the entity-header fields corresponding to the requested resource 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 the end server.
201 Created
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 entity of the response,
with the most specific URL for the resource given by a Location header field. The origin
server MUST create the resource before returning the 201 status code. If the action cannot
be carried out immediately, the server should respond with 202 (Accepted) response
instead.
202 Accepted
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 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 fulfilled.
203 Non-Authoritative Information
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. Use of this response code is not required and
is only appropriate when the response would otherwise be 200 (OK).
204 No Content
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 from that which caused the
request to be sent. This response is primarily intended to allow input for actions to take
place without causing a change to the user agent's active document view. The response MAY
include new metainformation in the form of entity-headers, which SHOULD apply to the
document currently in the user agent's active view.
The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
205 Reset Content
The server has fulfilled the request and the user agent SHOULD reset the document view
which caused the request to be sent. This response is primarily intended to allow input
for actions to take place via user input, followed by a clearing of the form in which the
input is given so that the user can easily initiate another input action. The response
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.36) indicating the desired range , and may have
included an If-Range header field (section 14.27) to make the request conditional.
The response MUST include the following header fields:
If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity- headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.
A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see 13.5.4.
A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses.
300 Multiple Choices
The requested resource corresponds to any one of a set of representations, each with its
own specific location, and agent-driven negotiation information (section 12) is being
provided so that the user (or user agent) can select a preferred representation and
redirect its request to that location.
Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or 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. However, this specification does not define any standard for such automatic selection.
If the server has a preferred choice of representation, it SHOULD include the specific URL for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cachable unless indicated otherwise.
301 Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to
this resource SHOULD be done using one of the returned URIs. Clients with link editing
capabilities SHOULD automatically re-link references to the Request-URI to one or more of
the new references returned by the server, where possible. This response is cachable
unless indicated otherwise.
If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD 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.
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
302 Moved Temporarily
The requested resource resides temporarily under a different URI. Since the redirection
may be altered on occasion, the client SHOULD continue to use the Request-URI for future
requests. This response is only cachable if indicated by a Cache-Control or Expires header
field.
If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain 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 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.
Note: When automatically redirecting a POST request after receiving a 302 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
303 See Other
The response to the request can be found under a different URI and SHOULD be retrieved
using a GET method on that resource. This method exists primarily to allow the output of a
POST-activated script to redirect the user agent to a selected resource. The new URI is
not a substitute reference for the originally requested resource. The 303 response is not
cachable, but the response to the second (redirected) request MAY be cachable.
If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
304 Not Modified
If the client has performed a conditional GET request and access is allowed, but the
document has not been modified, the server SHOULD respond with this status code. The
response MUST NOT contain a message-body.
The response MUST include the following header fields:
Date, unless its omission is required by section 14.19.1 If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate 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 might differ from that sent in any previous response or the same variant If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.
If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.
The 304 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
305 Use Proxy
The 305 is generated by an origin server to indicate that the client, or proxy, should use
a proxy to access the requested resource.
The request SHOULD be accompanied by a Set-Proxy response header indicating what proxy is to be used. The client will parse the Set-Proxy header as defined below to decide how long and for what URLs it should use the specified proxy.
If the 305 response is not accompanied by a Set-Proxy header, it MUST be accompanied by a Location header. The Location header will specify a URL to the proxy.
If both headers are present in the response, the client SHOULD only use the Set-Proxy header only.
306 Switch Proxy
The 306 response is generated by a proxy server to indicate that the client or proxy
should use the information in the accompanying Set-Proxy header to choose a proxy for
subsequent requests.
The 306 response code MUST be accompanied by the Set-Proxy response header. The client or proxy will parse the Set- Proxy header to determine which proxy to use, how long to use it, and for which URLs to use it.
The scope in the Set-Proxy header is considered an optional advisory. The client or proxy may choose to ignore it, and use it for just this request, for all requests, or for a scope previously or implicitly defined by another configuration method or autoconfiguration system.
400 Bad Request
The request could not be understood by the server due to malformed syntax. The client
SHOULD NOT repeat the request without modifications.
401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate
header field (section 14.46) containing a challenge applicable to the requested resource.
The client MAY repeat the request with a suitable Authorization header field (section
14.8). If the request already included Authorization credentials, then the 401 response
indicates that authorization has been refused for those credentials. If the 401 response
contains the same challenge as the prior response, and the user agent has already
attempted authentication at least once, then the user SHOULD be presented the entity that