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

The Apache server implements format negotiation using two non-CGI-based mechanisms. One method requires that the Web or document administrator create a special map file containing information about the different data variants. As an example, consider the following map file monty_python.image :

URI: monty_python; vary="type"

URI: monty_python.jpeg
Content-type: image/jpeg; qs=0.85

URI: monty_python.gif
Content-type image/gif; qs=0.5

URI: monty_python.xpm
Content-type: image/xpm; qs=0.2

The content indicates that there are three different image variants for this file, accessible at the indicated Uniform Resource Identifier (URI, equivalent here to a URL, as discussed at the end of Chapter 8), and describes the relative qualities of the images (through the parameter qs). A URL pointing to the file monty_python.image will retrieve the appropriate image file from amongst the three possible formats, depending on the accept headers sent by the client.

The map file can also contain content-language, content-encoding, and content-length fields to define the language, encoding, and length of each resource variant.

The second method of format negotiation implemented on the Apache server is known as MultiViews. This method lets a user request a generic resource minus the filename extension, for example http://.../path/monty_python, whereupon the server locates all files with this suffix in the indicated directory, and dynamically creates a map file similar to the one above (but without qs parameters). The server then uses the accept headers to determine which file to return to the client.

HTTP Methods and Header Fields Reference

The following sections summarize the HTTP methods, request headers, response headers, and server error messages currently defined and in use. These are predominately HTTP 1.0 values, but some HTTP 1.1 values are in common use on experimental HTTP servers and are also presented here.

HTTP Methods Specification

Table 9.1 summarizes the defined HTTP methods—the commonly implemented methods are GET, HEAD, and POST, which were discussed in detail in this chapter.

HTTP Request Header Field Specifications

Request header fields can be divided into two broad categories: (A) those that describe the status and properties of the server and of the client-server connection and (B) those describing the status and properties of the data (if any) being sent by the client.

(A) Client and Connection Status Header Fields

These header fields define the properties of the requesting client and of the client-server connection, such as the client capabilities, authentication information, required by the connection, and so on.

      Accept: type/subtype, type/subtype2...

Contains a list of MIME content-types acceptable to the client, separated by commas. Types can also contain parameters describing their relative merit (q=0.0 to q=0.1) and the maximum allowed size for a resource (mxb=num_bytes). The use of these terms was discussed earlier in this chapter.

      Accept-Charset: charset1, charset2...

Lists the character sets preferred by the browser, other than the default (ASCII or ISO Latin-1). Thus the server, if capable, can deliver the resource using the character set preferred by the browser. This is sent by Netscape Navigator 4.

      Accept-Encoding: enc_type1, enc_type2...

Lists the data encoding types acceptable to the client. For example,

      Accept-Encoding: x-compress

tells the server that the client can accept compressed data in the compress format. Currently understood encoding types are x-compress and x-gzip, which may also be seen under the names compress and gzip. Other possible (but largely unimplemented) encoding types are base64 and quoted-printable. If a server sends a document in one of these encodings, it must include the appropriate Content-encoding response header.

      Accept-language: lang1, lang2...

This field lists the languages preferred by the browser. (For the schemes used to specify the languages, see Appendix E available from the companion Web site at www.wiley.com/compbooks/graham. For example, the field

      Accept-language fr-ca, fr, en

would mean that the browser prefers Canadian French, will accept standard French if Canadian French is not available, and lastly, will accept English if the other two are not available.

      Authorization: scheme scheme_data

This passes user authentication and encryption scheme information to the server. Scheme indicates the authorization scheme to be used, with scheme_data containing scheme-specific authorization data. If authentication is not required, this field is absent.

Several HTTP 1.0 servers support keep-alive connections. If a browser sends the header field

      Connection: keep-alive

a server that supports keep-alive will not close the client-server link, allowing the client to send several requests down the still-open connection.

In HTTP 1.1, all connections are by default kept-alive and are consequently called persistent connections. Thus, in HTTP 1.1, the connection field is used to close the connection rather than keep it open. The connection header field that closes a connection is:

      Connection: close

Only browsers that understand HTTP 1.1 will send this header.

This passes stored state information from the client to server. Servers can use a special Set-Cookie: response header to place state information, in the form of name/value pairs, on a client. The client will then return this information, but only to the server that originally sent the “cookie.” This Netscape extension is supported by some but not all clients. Details of the mechanism are found in Chapter 10.

      Date: date_time

Gives the time and date when the current object was assembled for transmission. Note that the time must be Greenwich Mean Time (GMT) to ensure that all servers share a common time zone. Possible formats for the date_time string are discussed at the end of this chapter.

      From: mail_address

Contains the address, in Internet mail format, of the user accessing the server. In general, a browser does not send this information out of concern for a user’s privacy.

Contains the domain name and port number (optional if port 80) to which the request is being directed. This is useful if the request is passing through a proxy server or if the request is to a server that has more than one domain name or IP address. This is not sent by all browsers.

      If-Modified-Since: date_time

Sent with a GET request to make the GET conditional—if the requested document has not changed since the indicated time and date, the server does not send the document. Possible formats for the date_time string are discussed at the end of this chapter. If the document is not sent, the server should send the response header message 304 (not modified).

      Pragma: server_directive

Pragma directives pass special-purpose information to servers. Currently, there is only one server directive, Pragma: no-cache, which tells a proxy server (or servers, if it takes multiple proxy servers to reach the resource) to always fetch the document from the actual server and to never use a locally cached copy.

      Referer: URL

Gives the URL of the document from which the request originated. This can be a partial URL, in which case it is interpreted relative to the URL of the document being requested. If a document contains an HTML BASE element, then the URL referenced by this element should be sent instead.

      User-Agent: program /version comments

Provides information about the client software making the request.