HTTP Response Message Format

Up and down; east and west; black and white; yin and yang. Well, you get the idea. Each request message sent by an HTTP client to a server prompts the server to send back aresponse message. Actually, in certain cases the server may in fact send two responses, a preliminary response followed by the real one. Usually though, one request yields one response, which indicates the results of the server's processing of the request, and often also carries an entity (file or resource) in the message body.

Like requests, responses use their own specific message format that is based on theHTTP generic message format. The format, shown inFigure 318, is:

<status-line>
<general-headers>
<response-headers>
<entity-headers>
<empty-line>
[<message-body>]
[<message-trailers>]

Figure 318: HTTP Response Message Format

This figure illustrates the construction of an HTTP response, and includes an example of both message headers and body. The status code “200” indicates that this is a successful response to a request; it contains a brief text HTML entity in the message body. See Figure 317 for the HTTP request format.

Status Line

The status line—not “response line”, note—is the start line used for response messages. It has two functions: to tell the client what version of the protocol the server is using, and to communicate a summary of the results of processing the client's request. The formal syntax for the status line is:

<HTTP-VERSION> <status-code> <reason-phrase>

HTTP Version

The HTTP-VERSION label in the status line serves the same purpose as it does in therequest line of a request message; here, it tells the client the version number that the server is using for its response. It uses the same format as in the request line, in upper case as “HTTP/0.9”, “HTTP/1.0” or “HTTP/1.1”. The server is required to return an HTTP version number that is no greater than that the client sent in its request.

Status Code and Reason Phrase

The status code and reason phrase provide information about the results of processing the client's request in two different forms. The status code is a three-digit number that indicates the formal result that the server is communicating to the client; it is intended for the client HTTP implementation to process so the software can take appropriate action. The reason phrase is an additional, descriptive text string, which can be displayed to the human user of the HTTP client so he or she can see how the server responded.I describe status codes and reason phrases later in this section, and also list all of the standard codes.

Status Code Format

HTTP status codes are three digits in length and follow a particular format where the first digit has particular significance. Unlike FTP and the others, the second digit does not stand for a functional grouping; the second and third digits together just make 100 different options for each of the categories indicated by the first digit. Thus, the general form of an HTTP status code is “xyy”, where the first digit, “x”, is specified as given inTable 274.

Table 274: HTTP Status Code Format: First Digit Interpretation

Status Code Format

Meaning

Description

1yy

Informational Message

Provides general information; does not indicate success or failure of a request.

2yy

Success

The method was received, understood and accepted by the server.

3yy

Redirection

The request did not fail outright, but additional action is needed before it can be successfully completed.

4yy

Client Error

The request was invalid, contained bad syntax or could not be completed for some other reason that the server believes was the client's fault.

5yy

Server Error

The request was valid but the server was unable to complete it due to a problem of its own.

In each of these five groups, the code where “yy” is “00” is defined as a “generic” status code for that group, while other two-digit combinations are more specific responses. For example, “404” is the well-known specific error message that means the requested resource was not found by the server, while “400” is the less specific “bad request” error. This system was set up to allow the definition of new status codes that certain clients might not comprehend. If a client receives a strange code, it just treats it as the equivalent of the generic response in the appropriate category. So if a server response starts with the code “491” and the client has no idea what this is, it just treats it as a 400 “bad request” reply.

Reason Phrases

The reason phrase is a text string that provides a more meaningful description of the error for people who are bad at remembering what cryptic codes stand for (which would be most of us!) The HTTP standard includes “sample” reason phrases for each status code, but these can be customized by the administrators of a server if desired. When a server returns a more detailed HTML error message in the body of its response message, the reason phrase is often used for the “title” tag in that message body.

Key Concept:Each HTTP response includes both a numericstatus code and a textreason phrase, both of which indicate the disposition of the corresponding client request. The numeric code allows software programs to easily interpret the results of a request, while the text phrase provides more useful information to human users. HTTP status codes are three digits in length, with the first digit indicating the general class of the reply.

eaders

The response message will always include a number of headers that provide extra information about it. Response message headers fall into these categories:

• General Headers: General headers that refer to the message itself and are not specific to response messages or the entity in the message body. These are the same as the generic headers that can appear in request messages (though certain headers appear more often in responses and others are more common in requests).
  
  
• Response Headers: These headers provide additional data that expands upon the summary result information in the status line. The server may also return extra result information in the body of the message, especially when an error occurs, as discussed below.
  
  
• Entity Headers: These are headers that describe the entity contained in the body of the response, if any. These are the same entity headers that can appear in a request message, but they are seen more often in response messages. The reason for this is simply that responses more often carry an entity than requests, because most requests are to retrieve a resource.

Note:Entity headers may appear in a response to describe the resource that is the subject of the request, even if the entity itself is not sent in the message. This occurs when theHEAD method is used to request only the headers associated with an entity.

Response headers are of course used only in response messages, while the others are general with respect to message type.See the section describing HTTP headers for more details.

Most response messages contain an entity in the message body. In the case of a successful request to retrieve a resource, this is the resource itself. Responses indicating unsuccessful requests usually contain detailed error information, often in the form of an HTML-formatted error message.

Key Concept:Each HTTP request sent by a client leads to a server returning one or moreHTTP responses. Each response message starts with a status line that contains the server’s HTTP version number, and a numericstatus code and textreason phrase that indicate the result of processing the client’s request. The message then contains headers related to the response, followed by a blank line and then the optional message body. Since most HTTP requests ask for a server to return a file or other resource, many HTTP responses carry an entity in the message body.

 

Table 275: HTTP Status Codes

Status Code

Reason Phrase

Description

100

Continue

Client should continue sending its request. This is a special status code; see below for details.

101

Switching Protocols

The client has used the Upgrade header to request the use of an alternative protocol and the server has agreed.

200

OK

Generic successful request message response. This is the code sent most often when a request is filled normally.

201

Created

The request was successful and resulted in a resource being created. This would be a typical response to aPUT method.

202

Accepted

The request was accepted by the server but has not yet been processed. This is an intentionally “non-commital” response that does not tell the client whether or not the request will be carried out; the client determines the eventual disposition of the request in some unspecified way. It is used only in special circumstances.

203

Non-Authoritative Information

The request was successful, but some of the information returned by the server came not from the original server associated with the resource but from a third party.

204

No Content

The request was successful, but the server has determined that it does not need to return to the client an entity body.

205

Reset Content

The request was successful; the server is telling the client that it should reset the document from which the request was generated so that a duplicate request is not sent. This code is intended for use with forms.

206

Partial Content

The server has successfully fulfilled a partial GET request.See the topic on methods for more details on this, as well asthe description of the Range header.

300

Multiple Choices

The resource is represented in more than one way on the server. The server is returning information describing these representations, so the client can pick the most appropriate one, a process calledagent-driven negotiation.

301

Moved Permanently

The resource requested has been moved to a new URL permanently. Any future requests for this resource should use the new URL.

This is the proper method of handling situations where a file on a server is renamed or moved to a new directory. Most people don't bother setting this up, which is why URLs “break” so often, resulting in 404 errors as discussed below.

302

Found

The resource requested is temporarily using a different URL. The client should continue to use the original URL. See code 307.

303

See Other

The response for the request can be found at a different URL, which the server specifies. The client must do a freshGET on that URL to see the results of the prior request.

304

Not Modified

The client sent a conditional GET request, but the resource has not been modified since the specified date/time, so the server has not sent it.

305

Use Proxy

To access the requested resource, the client must use a proxy, whose URL is given by the server in its response.

306

(unused)

Defined in an earlier (draft?) version of HTTP and no longer used.

307

Temporary Redirect

The resource is temporarily located at a different URL than the one the client specified.

Note that 302 and 307 are basically the same status code. 307 was created to clear up some confusion related to 302 that occurred in earlier versions of HTTP (which I'd rather not get into!)

400

Bad Request

Server says, “huh?” J Generic response when the request cannot be understood or carried out due to a problem on the client's end.

401

Unauthorized

The client is not authorized to access the resource. Often returned if an attempt is made to access a resource protected by a password or some other means without the appropriate credentials.

402

Payment Required

This is reserved for future use. Its mere presence in the HTTP standard has caused a lot of people to scratch their chins and go “hmm…”J

403

Forbidden

The request has been disallowed by the server. This is a generic “no way” response that is not related to authorization. For example, if the maintainer of Web site blocks access to it from a particular client, any requests from that client will result in a 403 reply.

404

Not Found

The most common HTTP error message, returned when the server cannot locate the requested resource. Usually occurs due to either the server having moved/removed the resource, or the client giving an invalid URL (misspellings being the most common cause.)

405

Method Not Allowed

The requested method is not allowed for the specified resource. The response includes anAllow header that indicates what methods the server will permit.

406

Not Acceptable

The client sent a request that specifies limitations that the server cannot meet for the specified resource. This error may occur if an overly-restrictive list of conditions is placed into a request such that the server cannot return any part of the resource.

407

Proxy Authentication Required

Similar to 401, but the client must first authenticate itself with theproxy.

408

Request Timeout

The server was expecting the client to send a request within a particular time frame and the client didn't send it.

409

Conflict

The request could not be filled because of a conflict of some sort related to the resource. This most often occurs in response to aPUT method, such as if one user tries to PUT a resource that another user has open for editing, for example.

410

Gone

The resource is no longer available at the server, which does not know its new URL. This is a more specific version of the 404 code that is used only if the server knows that the resource was intentionally removed. It is seen rarely (if ever) compared to 404.

411

Length Required

The request requires a Content-Length header field and one was not included.

412

Precondition Failed

Indicates that the client specified a precondition in its request, such as the use of anIf-Match header, which evaluated to a false value. This indicates that the condition was not satisfied so the request is not being filled. This is used by clients in special cases to ensure that they do not accidentally receive the wrong resource.

413

Request Entity Too Large

The server has refused to fulfill the request because the entity that the client is requesting is too large.

414

Request-URI Too Long

The server has refused to fulfill the request because the URL specified is longer than the server can process. This rarely occurs with properly-formed URLs but may be seen if clients try to send gibberish to the server.

415

Unsupported Media Type

The request cannot be processed because it contains an entity using a media type the server does not support.

416

Requested Range Not Satisfiable

The client included a Range header specifying a range of values that is not valid for the resource. An example might be requesting bytes 3,000 through 4,000 of a 2,400-byte file.

417

Expectation Failed

The request included an Expect header that could not be satisfied by the server.

500

Internal Server Error

Generic error message indicating that the request could not be fulfilled due to a server problem.

501

Not Implemented

The server does not know how to carry out the request, so it cannot satisfy it.

502

Bad Gateway

The server, while acting as a gateway or proxy, received an invalid response from another server it tried to access on the client's behalf.

503

Service Unavailable

The server is temporarily unable to fulfill the request for internal reasons. This is often returned when a server is overloaded or down for maintenance.

504

Gateway Timeout

The server, while acting as a gateway or proxy, timed out while waiting for a response from another server it tried to access on the client's behalf.

505

HTTP Version Not Supported

The request used a version of HTTP that the server does not understand.