10 Status Code Definitions
Each Status-Code is described below, including a description of which
method(s) it can follow and any metainformation required in the
response.
Fielding, et. al. Standards Track [Page 53]
RFC 2068 HTTP/1.1 January 1997
10.1 Informational 1xx
This class of status code indicates a provisional response,
consisting only of the Status-Line and optional headers, and is
terminated by an empty line. Since HTTP/1.0 did not define any 1xx
status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
client except under experimental conditions.
10.1.1 100 Continue
The client may continue with its request. This interim response is
used to inform the client that the initial part of the request has
been received and has not yet been rejected by the server. The client
SHOULD continue by sending the remainder of the request or, if the
request has already been completed, ignore this response. The server
MUST send a final response after the request has been completed.
10.1.2 101 Switching Protocols
The server understands and is willing to comply with the client's
request, via the Upgrade message header field (section 14.41), for a
change in the application protocol being used on this connection. The
server will switch protocols to those defined by the response's
Upgrade header field immediately after the empty line which
terminates the 101 response.
The protocol should only be switched when it is advantageous to do
so. For example, switching to a newer version of HTTP is
advantageous over older versions, and switching to a real-time,
synchronous protocol may be advantageous when delivering resources
that use such features.
10.2 Successful 2xx
This class of status code indicates that the client's request was
successfully received, understood, and accepted.
10.2.1 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;
Fielding, et. al. Standards Track [Page 54]
RFC 2068 HTTP/1.1 January 1997
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end
server.
10.2.2 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.
10.2.3 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.