Saturday, February 23, 2008
The following is a list of HTTP response status codes and standard associated phrases, intended to give a short textual description of the status. These status codes are specified by RFC 2616, along with additional codes (RFC 2518, RFC 2817, RFC 2295, RFC 2774, RFC 4918), some from the Distributed Authoring (WebDAV) extension. Others are unstandardised but commonly used.
The first digit of the status code specifies one of five classes of response.
The client must take additional action to complete the request.
Indicates multiple options for the URI that the client may follow. It, for instance, could be used to present different format options for video, list files with different extensions, or word sense disambiguation.
This and all future requests should be directed to the given URI.
This is the most popular redirect code, but also an example of industrial practice contradicting the standard. HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"), but popular browsers implemented it as a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to disambiguate between the two behaviors. However, the majority of Web applications and frameworks still use the 302 status code as if it were the 303.
The response to the request can be found under another URI using a GET method.
Indicates the request URL has not been modified since last requested. Typically, the HTTP client provides a header like the If-Modified-Since header to provide a time with which to compare against. Utilizing this saves bandwidth and reprocessing on both the server and client.
Many HTTP clients (such as Mozilla  and Internet Explorer) don't correctly handle responses with this status code, primarily for security reasons.
No longer used.
In this occasion, the request should be repeated with another URI, but future requests can still be directed to the original URI. In contrast to 303, the request method should not be changed when reissuing the original request. For instance, a POST request must be repeated using another POST request.
The request contains bad syntax or cannot be fulfilled.
Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided. See Basic access authentication and Digest access authentication.
The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, but that has not happened, and this code has never been used.
The request was a legal request, but the server is refusing to respond to it. Unlike a 401 Unauthorized response, authenticating will make no difference.
A request was made to a URL using a request method not supported by that URL; for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource
Indicates that the resource requested is no longer available and will not be available again. This should be used when a resource has been intentionally removed; however, in practice, a 404 Not Found is often issued instead.
The request was well-formed but was unable to be followed due to semantic errors.
The resource that is being accessed is locked
The request failed due to failure of a previous request (e.g. a PROPPATCH).
Defined in drafts of WebDav Advanced Collections, but not present in "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol" (RFC 3648).
The client should switch to TLS/1.0.
A Microsoft extension: The request should be retried after doing the appropriate action.
5xx Server Error
Hypertext Transfer Protocol
Posted by imarealist hoi at 9:11 AM