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

GET /Tests/file.html HTTP/1.0
Referer: <http://www.utoronto.ca/webdocs/webinfo.html>
Connection: Keep-Alive
Cookie: good=bad; apples=oranges
User-Agent: Mozilla/3.0b5 (Win95; I)
Host: smaug.java.utoronto.ca:2021
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en-US, fr
Accept-Charset: ISO-8859-1,*,UCS-2
    [a blank line, containing only CRLF ]

Client Request: Host Field (HTTP 1.0 Extension; HTTP 1.1)

The host field, of the form Host: domain_name:port gives the domain name and port to which the client has directed its request—if the port is absent, the default value (80) is assumed. This field may seem superfluous, but is useful if the request passes through a proxy server or is directed to a server that has more than one domain name. This header is sent by Internet Explorer 3 and greater, and Netscape Navigator 3 and greater.

This header was adopted as an HTTP 1.0 extension. Its use in HTTP 1.1 is the same as that described above. In HTTP 1.1, it is an error if a request header does not have this field.

Client Request: User-Agent Field

Note how the user-agent field in Figure 9.3 indicates that the browser (MSIE 3.0B) is compatible with Netscape 2.0 (Mozilla). The field also gives the display resolution of the computer (1024 by 768). The placement or inclusion of such data is nonstandardized, so you cannot count on this information being present—indeed, this information is not found in the Internet Explorer 4 user-agent field.

Client Request: Connection Field (HTTP 1.0 Extension; also HTTP 1.1)

Figure 9.4 illustrates the connection header field of the form Connection: keep-alive. This is used to keep the TCP/IP connection open after the requested resource has been sent to the client. As mentioned in the introduction, HTTP 1.0 was designed to break this connection as soon as the data were sent. This can be very inefficient if a browser requests several subsequent files from the same server (such as an HTML document plus all the inline graphics). If the browser sends an HTTP 1.0 keep-alive header field, servers that understand this header will keep the connection open for a short time (usually 10–15 seconds) in preparation for the next request.

As seen in Figures 9.3 and 9.4, not all browsers support keep-alive. Similarly, not all servers support this feature, and instead simply ignore this field. Finally, a server will use keep-alive only if it can return a content-length response header field for the data it returns—with keep-alive, the content-length field is the only way a client can determine if all the data have been sent by the server, whereupon it can make another request.

The connection field was introduced as an extension to HTTP 1.0, but the mechanism used for maintaining a connection led to a number of problems that could only be resolved by significantly modifying the keep-alive mechanism. Thus, while HTTP 1.1 supports the connection field and the value “keep-alive,” the mechanism used is very different from that in HTTP 1.0—in HTTP 1.1, the default is to keep the connection “open,” and the connection field is used to close it. You are referred to the HTTP 1.1 standard for the details.

Client Request: Cookie Fields (HTTP 1.0 Extension)

Netscape introduced a special header field mechanism commonly called Netscape cookies —this is a mechanism that lets a server store small pieces information on a browser. This information is sent to the client using a Set-cookie server response header. A browser that understands cookies will store the data on the client machine’s hard disk and will return these data to the server from which the cookie originated, within a cookie request header field.

Cookies are useful for storing state information (e.g., the time at which the user last visited the site, which resources the user last used, etc.) on the browser in such a way that the information is not lost when the user leaves the site or shuts down his or her browser. However, note that not all browsers support cookies, while browsers that do support cookies give the user the option of disabling this feature.

Detailed information about the cookie mechanism is found in Chapter 10.

Lessons from Example 14

1.  Most browsers send a Host request field, which gives the domain name and port number to which the request is being directed. Some also send an accept-language field, to indicate the language(s) preferred by the user.

2.  The User-agent field may contain browser-specific information, such as the monitor display resolution. There is no standardized way for including this information.

3.  Some browsers also send a Connection: keep-alive header field to stop the server from breaking the connection after the server has sent the requested data. Not all browsers or servers support this feature. Note that the HTTP 1.1 implementation of keep-alive is very different from the implementation in HTTP 1.0.

4.  Using the Set-cookie response header fields and the Netscape cookie mechanism is a useful way of storing state information about the client-server session. However, not all browsers support this mechanism.

HEAD Method: Information about a Resource

In some cases, it is useful to gather information about a resource without retrieving the resource itself. For example, a link-checking program does not always need to retrieve a resource to verify that the resource exists, while an indexing package may only want to know if a resource has changed since it was last catalogued, prior to deciding if it should be retrieved.

This role is satisfied by the HTTP HEAD method, which requests that a server send the response header relevant to the requested URL, but not the content of the referenced object. As the following example indicates, this is a quick way of seeing if a document or gateway program is actually present and of obtaining some general information about it, such as its MIME content-type or the date it was last modified, without downloading the entire resource.