HTTP Message Flow and Message Parts - Part 1 of Chapter 3 from HTTP: The Definitive Guide (3/7) | WebReference

HTTP Message Flow and Message Parts - Part 1 of Chapter 3 from HTTP: The Definitive Guide (3/7)

To page 1To page 2current pageTo page 4To page 5To page 6To page 7
[previous] [next]

HTTP: The Definitive Guide, Chapter 3: HTTP Messages

Message Syntax

All HTTP messages fall into two types: request messages and response messages.Request messages request an action from a web server. Response messages carry results of a request back to a client. Both request and response messages have the same basic message structure. Figure 3-4 shows request and response messages to get a GIF image.

An HTTP transaction has request and response messages
Figure 3-4. An HTTP transaction has request and response messages

Here's the format for a request message:

<method> <request-URL> <version>
<headers>
 
<entity-body>

Here's the format for a response message (note that the syntax differs only in the start line):

<version> <status> <reason-phrase>
<headers>
 
<entity-body>

Here's a quick description of the various parts:

method
The action that the client wants the server to perform on the resource. It is a single word, like "GET," "HEAD," or "POST". We cover the method in detail later in this chapter.

request-URL
A complete URL naming the requested resource, or the path component of the URL. If you are talking directly to the server, the path component of the URL is usually okay as long as it is the absolute path to the resource--the server can assume itself as the host/port of the URL. Chapter 2 covers URL syntax in detail.

version
The version of HTTP that the message is using. Its format looks like:
HTTP/<major>.<minor>
where major and minor both are integers. We discuss HTTP versioning a bit more later in this chapter.

status-code
A three-digit number describing what happened during the request. The first digit of each code describes the general class of status ("success," "error," etc.). An exhaustive list of status codes defined in the HTTP specification and their meanings is provided later in this chapter.

reason-phrase
A human-readable version of the numeric status code, consisting of all the text until the end-of-line sequence. Example reason phrases for all the status codes defined in the HTTP specification are provided later in this chapter. The reason phrase is meant solely for human consumption, so, for example, response lines containing "HTTP/1.0 200 NOT OK" and "HTTP/1.0 200 OK" should be treated as equivalent success indications, despite the reason phrases suggesting otherwise.

headers
Zero or more headers, each of which is a name, followed by a colon (:), followed by optional whitespace, followed by a value, followed by a CRLF. The headers are terminated by a blank line (CRLF), marking the end of the list of headers and the beginning of the entity body. Some versions of HTTP, such as HTTP/1.1, require certain headers to be present for the request or response message to be valid. The various HTTP headers are covered later in this chapter.

entity-body
The entity body contains a block of arbitrary data. Not all messages contain entity bodies, so sometimes a message terminates with a bare CRLF. We discuss entities in detail in Chapter 15.

Figure 3-5 demonstrates hypothetical request and response messages.

Example request and response messages
Figure 3-5. Example request and response messages

Note that a set of HTTP headers should always end in a blank line (bare CRLF), even if there are no headers and even if there is no entity body. Historically, however, many clients and servers (mistakenly) omitted the final CRLF if there was no entity body. To interoperate with these popular but noncompliant implementations, clients and servers should accept messages that end without the final CRLF.


To page 1To page 2current pageTo page 4To page 5To page 6To page 7
[previous] [next]

Created: January 13, 2003
Revised: January 13, 2003

URL: https://webreference.com/programming/http/chap3/1/3.html