As you can probably guess from Table 2.1, the HTTP protocol defines a client/server model. The difference between HTTP and typical client/server protocols, however, is that either role can be played by either computer involved in the conversation. The role a given computer plays during the conversation depends on the resource being accessed and possibly the HTML contained by the resource.
Another very important difference is the fact that the HTTP is a stateless protocol. Users are not required to go through a logon process, which is typical of most client/server systems. In fact, the majority of HTTP data transfers are completely anonymous-beyond the machine address of the client, the server has no knowledge of who is retrieving data from it. In addition to the lack of user information, the HTTP protocol provides no mechanism for tracking how long a client may actually utilize information it has retrieved or for knowing what a client may have done before requesting a resource from the server.
The typical HTTP conversation contains the following steps, which are illustrated in Figure 2.2.
1. A client opens a connection with a server. Recall that any computer can act as a client, even if the computer is running a server application.
2. The client sends a request to the server. This request consists of a request method, a resource or service address, and possibly other header fields, and body content. These concepts are discussed in the following sections.
3. The server returns to the client a status line, possible header information, and (usually) an entity section.
4. The server closes the connection.
There is always the possibility on the global Internet that a connection can fail at any time. The HTTP protocol provides that both the client and server applications must be prepared for such a situation. The loss of connection can occur due to user interaction, a communication time-out, or an application failure. A loss of connection is considered to terminate the client's current request. This means that, regardless of the state of the request when the termination occurs, the client must restart the entire process to properly attempt to access the resource again.
In addition to this drawback, the HTTP protocol allows for only a single resource to be transferred during a connection. This means that if a hypertext page has embedded references to other resources (such as images), the client must retrieve each resource individually through separate connections. For example, to construct the Web page of Figure 2.1, the Web browser had to make three connections. One to retrieve the HTML file, another to retrieve the embedded Java applet, and a third to retrieve the Under Construction picture. This shortcoming of HTTP has often been blamed for the slow response time of the Web.
