Informational 1xx
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.
Successful 2xx
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.
Redirection 3xx
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.
