| The HTTP response message consists of an initial status line, one or more header fields, a blank line (CRLF) and an optional message body. The status line consists of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by space (SP) characters, as follows: Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF The Status-Code element is a three-digit integer result code of the attempt to understand and satisfy the request. The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. The Reason-Phrase is intended to give a short textual description of the Status-Code; the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase. HTTP Status Codes The HTTP status codes and their corresponding Reason-Phrases as defined in RFC 2616 are as follows: 1xx: Informational The request was received; continuing process. 100 Continue 101 Switching Protocols
2xx: Success The action was successfully received, understood, and accepted. 3xx: Redirection Further action must be taken in order to complete the request. 300 Multiple Choices 301 Moved Permanently 302 Found 303 See Other 304 Not Modified 305 Use Proxy 307 Temporary Redirect
4xx: Client Error The request contains bad syntax or cannot be fulfilled. 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Time-out 409 Conflict 410 Gone 411 Length Required 412 Precondition Failed 413 Request Entity Too Large 414 Request-URI Too Large 415 Unsupported Media Type 416 Requested Range Not Satisfiable 417 Expectation Failed
5xx: Server Error The server failed to fulfill an apparently valid request. 505 HTTP Version Not Supported
HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached. Response Header Fields The response header fields allow the server to pass additional information about the response that cannot be placed in the status line. The header fields give information about the server and about further access to the resource identified by the Request-URI. The response header fields defined in RFC 2616 are as follows: The Accept-Ranges header field allows the server to indicate its acceptance of range requests for a resource. The Age header field conveys the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server. A cached response is "fresh" if its age does not exceed its freshness lifetime. The ETag header field provides the current value of the entity tag for the requested variant. The Location header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource that was created by the request. For 3xx responses, the Location should indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI. The Proxy-Authenticate header field must be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI. The Retry-After header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. The Server header field contains information about the software used by the origin server to handle the request. The Vary header field value indicates the set of request header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation. For uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select the representation. A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the appropriate representation. The WWW-Authenticate header field must be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.
| 