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

Client Request: If-Modified-Since Field

A second common header is If-modified-since. This contains a time and date, in Greenwich Mean Time, and is used to conditionally retrieve a document (or data) only if the requested resource has been modified since the specified time and date. This is sent by browsers that cache local copies of data they have retrieved and records the date and time at which the file was cached. The browser then only needs a new copy of the file if it has changed since the browser last retrieved it. In Figure 9.1, the client sent the header:

If-Modified-Since: Wed, 02 Aug 1995 17:23:31 GMT

If the requested resource /path/file.html has been modified since this time and date, then the server sends a new copy to the client. If the resource has not been modified since this time and date, the server does not send a new copy and instead sends a special message indicating that the resource has not changed and that the client should use its existing copy. These messages are discussed in the upcoming section on server response.

Client Request: Referer Field

Another common field is Referer, which takes the general form Referer: URL. This field gives the URL of the document from which the request originated. In our example, we noted in the discussion that the user first accessed the document

www.utoronto.ca/webdocs/webinfo.html

and from there accessed the link producing the request shown in Figure 9.1. Thus, the header field

Referer: <http://www.utoronto.ca/webdocs/webinfo.html>

is part of the request header sent to the server. This header is sent by Netscape Navigator 3 and greater and by Internet Explorer 3 and greater.

Request Headers and Gateway Programs

In this example, the request headers are used by the server to determine whether a data file should be sent to the server, and if so, what type of data to send. (Servers can use the Accept: fields to decide from amongst a variety of different possible files to return. At present this feature, known as content or format negotiation, is implemented on several servers.) If the request references a gateway program, then the server cannot make this decision. Instead, the server passes all the request header information to the gateway program (as a collection of environment variables) and lets the gateway program decide what to do. Thus, a gateway program author must understand the meanings of these header fields, since he or she will have to write gateway programs that interpret them. A complete list of the possible request headers is given at the end of this chapter, in the section entitled “HTTP Request Header Field Specifications.”

The Server Response: Header and Data

When the server receives the request, it tries to apply the designated method (e.g., GET or POST) to the specified object (file or program) and passes the results of this effort back to the client. The returned data are preceded by a response header consisting of response header fields, which communicate information about the state of the transaction back to the client. As with the request header fields sent from client to server, these are single lines of text terminated by a CRLF, while the end of the response header is indicated by a single blank line containing only a CRLF. The data of the response follow the blank line.

Figure 9.2 shows the data returned by the server in response to the request of Figure 9.1.

The first six lines are the response header. The end of the response header is indicated by the single blank line. The data response of the request (in this case, the requested HTML document) follows this blank line.

Server Response: The Status Line

The first line in the response header is a status line, which lets the client know what protocol the server uses and whether or not the request was successfully completed. The general format for this line is:

HTTP/version  status_code  explanation

which in the example was:

HTTP/1.0 200 Document follows

The three components of this status line are:

HTTP/version The protocol version being used by the server, HTTP/1.0 in the example in Figure 9.2. If a client requests HTTP/1.1 but the server is only capable of HTTP/1.0, then the server should return HTTP/1.0 to indicate this fact.

status_code The status code for the response, as a number between 200 and 599. Values from 200 through 299 indicate successful transactions, while values 300–399 indicate redirection—the resource at the requested URL has moved. In this case, the server must also send the new URL of the object, if it is known (sent within a Location response header field). Numbers 400–599 are error messages. When an error occurs, the server usually sends a small HTML document explaining the error to help the user understand what happened and why. The status codes and their meanings are summarized in Table 9.2 at the end of this chapter.

Explanation A text string that provides descriptive information about the status. Explanation strings vary from server to server, whereas status codes and their meanings are explicitly defined by the HTTP specification.

HTTP/1.0 200 Document follows
Date: Sat, 13 Dec 1997 16:04:09 GMT
Server: NCSA/1.5.2
Content-tyre: text/html
Last-modified: Thu, 03 Oct 1996 16:03:27 GMT
Content-length: 139
      [a blank line, containing only CRLF ]
<html><head>
<title>  Test HTML file </title>
</head><body>
<h1> This is a test file</h1>
<p> So what did you expect, art?
</body></html>

In this example, the code 200 means that everything went fine and that the server is returning the requested data.

The remaining response header fields contain information about the server and about the response being sent. The example in Figure 9.2 returns six lines of response header information. The first two, the Date and Server fields give the date at which the message was sent and identify the server software, respectively, while the Content-type, Last-modified, and Content-length fields pass information specific to the document or data being returned. The formats and meanings of these header fields are described in the following sections.

Server Response: Date Field

This field, of the format Date: date_time, contains the time and date when the message was assembled for transmission. Note that the time must be Greenwich Mean Time (GMT) to ensure that all clients and servers share a common time zone. In the example, this field was:

Date: Sat, 13 Dec 1997 16:04:09 GMT

Note that this is not the date at which the data being returned was created or last modified—that information is contained in the Last-modified header field. Details about supported time formats are given at the end of the chapter.