HTML 4.0 Sourcebook
(Publisher: John Wiley & Sons, Inc.)
Author(s): Ian S. Graham
ISBN: 0471257249
Publication Date: 04/01/98

Illustration: Stateless Connections

Assume that a user retrieves, from a server, an HTML FORM containing a fill-in field for a user name—by typing in a name, the user is able to access name-specific information in a personnel database. When the user submits the FORM, the name (and any other information gathered by the FORM ) is sent to a gateway program residing on the server that processes of the request; the URL that references this gateway program is specified as a FORM element attribute, as discussed in Chapter 6.

This gateway program processes the data and returns a second HTML document containing the results, along with another FORM allowing further requests of the database. But, in this case, the FORM does not contain a place to type a name. Since the server is stateless and has no memory of the first connection, how will it know the name of the person when data from this second form are sent to the server?

The answer is that the server does not know the name. Rather, the application designer must write software such that the gateway programs explicitly keep track of this information. One way to do so is to hide the name information inside the FORM returned to the user. This can be accomplished using special hidden input elements of the form <INPUT TYPE="hidden" ...>. In the case of this simple example, the element might be:

<INPUT TYPE="hidden" NAME="name_of_person" VALUE="user_name">

Then, when the user submits the second FORM, the content of the hidden element is sent along with any new input, thereby returning the user name to the server.

Information that tracks the history of a sequence of transactions is often called state information. Using hidden elements, state information can be passed back and forth between client and server, preserving knowledge of the name for each subsequent transaction.

Example HTTP Client-Server Sessions

The easiest way to understand HTTP is through simple examples. The following sections present seven examples covering the most common HTTP methods. Each presentation shows both the data sent from the client to the HTTP server and the data returned from the server to the client. First, a few words about how this “eavesdropping” was accomplished.

Monitoring Client-Server Interaction

It is easy to monitor the interaction between HTTP servers and Web clients, since the communication is entirely in character data sent to a particular port (a port is a bit like a telephone extension, at which data can be sent or received). Consequently, all you need do is listen at a port or talk to a port. You can listen at a port using the program listen or backtalk,² while you can talk to a port using backtalk or the standard Internet program telnet.

---

²The programs listen and backtalk are available, in source code form, from the book’s supporting Web site, available at www.wiley.com/compbooks/graham/.

---

Client Sending to Server

You can use listen to find out what a Web client sends to a server. To do this, you run the listen program on a computer and make a Web client talk to listen. As an example, suppose listen is started on the computer with domain name leonardo.subnet.ca. When started, listen indicates the port number it is listening at by printing a message such as:

listening at port 1743

It then falls silent, waiting to print any data that arrive at this port. The next step is to configure a Web client so that it sends HTTP requests to this port. This is done by accessing a URL that points to port 1743 on leonardo.subnet.ca, for example:

http://leonardo.subnet.ca:1743/Tests/file.html

where the port number is marked in boldface. The client dutifully sends the HTTP request headers to port number 1743 on leonardo.subnet.ca, whereupon listen receives the data and prints them to the screen.

Server Sending to Client

Determining what the server sends back to the client takes a bit more work. In this case, you can use Telnet to connect to the server, but you must now enter by hand the HTTP request headers that are sent by a “real” client (and which you fortunately intercepted using the listen program, using the procedure described in the previous section). Suppose, for example, that a server is running at port 80 on leonardo.subnet.ca. You can connect to this server by simply making a telnet connection to this port. On a UNIX system, you would type (the typed command string is in boldface):

telnet leonardo.subnet.ca 80
Trying 128.100.121.33...
Connected to leonardo.subnet.ca
Escape character is '^]'.

Telnet gives three lines of information to explain what it is doing and then falls silent. Whatever you now type is sent to the server running on leonardo.subnet.ca, so you now type in the required request headers. Whatever the server sends in response is sent to the telnet program and printed on the screen.

Another useful tool is the program backtalk. Backtalk is a derivative of listen that allows you both to monitor data arriving at a port and send data to the remote program talking to that port. When launched, backtalk allocates a port and, like listen, prints out the port number, for example:

listening at port 1743

Thereafter, backtalk prints to the display anything that a remote program sends to port 1743, while anything typed into the console is sent out through port 1743 back to the remote program. Thus you can use backtalk to mimic the response of an HTTP server, albeit by hand. This is useful for examining client response to special server response headers, such as a request for user authentication.

Overview of Examples

The tools just described were used to determine the information passed between the client and server in several typical HTTP transactions. The examples that follow look at:

13.  a simple GET method request

14.  a simple GET method request, illustrating some newer header fields

15.  a HEAD method request for file meta-information

16.  a GET method request with a query string within the URL

17.  a GET method request arising from an HTML FORM submission

18.  a POST method request arising from an HTML FORM submission

19.  a file access request requiring “Basic” user authentication

To get the most out of these examples, you will need a basic understanding of URLs and of the way data are gathered by an HTML form and composed as a message for the server. These topics were covered in Chapters 6 (FORMs) and 8 (construction of query strings).