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

Server Response: Server Field

This field, of the format Server: name/version, returns the name and version of the server software, with a slash character separating the two. Some examples are:

Server: Netscape-Enterprise/2.01
Server: Apache/1.2.4
Server: Microsoft-IIS/4.0

Server-Response: Content-Type

This field, of the format Content-type: type/subtype, indicates the MIME Content-type of the data being sent from the server to the client. In this example, the returned data is an HTML document, so the returned header field is:

Content-type: text/html

MIME types are discussed in more detail in Appendix B, “Multipurpose Internet Mail Extensions,” available at the companion Web site at www.wiley.com/compbooks/graham. If no data are returned, this field is absent.

Server Response: Last-Modified

This field, of the format Last-modified: date_time, gives the date and time that the document was last modified. As with the Date field, the information must be given in Greenwich Mean Time. In the example, this field was:

Last-Modified: Thu, 03 Oct 1996 16:03:27 GMT

If the server does not know the date at which the resource was last modified, this field is absent.

Server Response: Content-Length Field

This field, of the format Content-length: length, gives the length in bytes of the data portion of the message. In some situations, the length is unknown (for example, if it is output from a gateway program), in which case this field is absent. In this event, the client will continue to read data until the server breaks the connection. If no data are returned, this field is absent. In the example, the message is 139 bytes long, so the header field is:

Content-length: 139

Server Generation of Response Header

How is the response header generated by the server? If the requested resource is a file, the HTTP server constructs the header itself. If the request is to a gateway program, then the gateway program must provide information about the details of the returned data, such as the Content-type, since only this program knows what is to be returned. There are two mechanisms that can be used by gateway programs to providing response header information. In the first, the gateway program returns server directives to the server—these are used by the server to create appropriate header fields, which are included with the full response header generated by the server. In the second mechanism, the gateway program returns a complete response header, which is sent directly to the remote client, bypassing processing by the server. This is called the non-parsed header gateway approach. Both methods are described in detail in Chapter 10.

Server Response If a File Has Not Changed

How does a server respond if the requested file was not modified subsequent to the time specified in the If-modified-since request header field? The resulting response is a short message of the form:

HTTP/1.0 304 Not Modified
Date: Sat, 13 Dec 1997 16:04:09 GMT
Server: NCSA/1.5.2
MIME-version: 1.0
  [Blank line, containing CRLF]

This contains the status code 304, which tells the client that the file was unchanged and that the client should use its cached copy of the data.

Lessons from Example 13

1.  When a client contacts an HTTP server, it sends a request header composed of request header fields. The first of these fields is the method field, which specifies the HTTP method being requested by the client and the location on the server of the resource being requested. This is followed by other header fields that pass information about the capabilities of the client. The request header is terminated by a single blank line, containing only a carriage-return linefeed (CRLF) character pair.

2.  The server responds with a message consisting of a response header followed by the requested data. The response header fields communicate information about the state of the transaction, including a MIME content-type header that explicitly tells the client the type of data being sent. The response header is terminated by a single blank line. The data being sent to the client follows this blank line.

Example 14: Other Common Request Header Fields

Modern browsers have extended the repertoire of request header fields, incorporating some fields proposed in HTTP 1.1 and others not part of the “official” HTTP 1.0 specification. For example, Figure 9.3 shows the request header produced by the Microsoft Internet Explorer 3.0 browser when making a request identical with that shown in Figure 9.1, while Figure 9.4 shows the header sent by the Netscape Navigator 3.0 browser. Both cases assume the request is made as described at the beginning of Example 13. New header fields are shown in boldface.

GET /Tests/file.html HTTP/1.0
Accept: */*
Referer: http://www.utoronto.ca/webdocs/webinfo.html
Accept-Language: en-US, fr
User-Agent: Mozilla/2.0 (compatible; MSIE 3.0; Windows 95;1024,768
Host: smaug.middle.earth.ca:2021
  [a blank line, containing only CRLF ]

Aside from somewhat cleaner header presentation (there are fewer superfluous accept header fields), there are three new fields as well as extra information in one of the User-agent fields. The purpose of these additions is described in the following sections.

Client Request: Accept-Charset Field

The accept-language field, of the form Accept-language: charset1, charset2, ..., gives a list of character sets supported by the browser; very few servers, however, support this field. Character set specifications are discussed in more detail in Appendix A, “Characters and Computer Character Sets,” available through the companion Web site at www.wiley.com/compbooks/graham. In Figure 9.4 the field accept-charset: ISO-8859-1,*,UCS-2 means that the client will accept the ISO-8859-1, UCS-2, or any character set. This header is currently sent by Netscape Navigator 4.

Client Request: Accept-Language Field

The accept-language field, of the form Accept-language: lang1, lang2 ..., gives a list of languages supported by the browser. This is similar to accept headers, but allows, in principle, for selection of different language versions of the same document. Some servers support this field, depending on how the request is made. Here, the field accept-language: en-Us, fr means that the client will accept English language (American version) or French language documents. This header is sent by Internet Explorer 3 and greater as well as Netscape Navigator 2 and greater. Language specifications are discussed in more detail in Appendix E, “Tags for Identifying Languages,” available through the companion Web site at www.wiley.com/compbooks/graham.