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

(B) Message Properties Header Fields

These header fields define specific properties of the message being sent (or about the requested resource, if the request method is HEAD). Certain fields may be absent, if they are inappropriate for the response data (e.g., content-language is irrelevant for an image file).

Content-language: lang

Gives the language in which the document is written. Note that this is not the same as the character set. At present, this field is not widely used with request headers.

Content-length: length

Gives the length, in bytes, of the message being sent to the server. If no message is sent, then this field is absent.

Content-type: type/subtype ; parameters

Gives the MIME content type of the message being sent to the server, with optional parameters for this type. If no message is sent, then this field is absent.

MIME-version: version_number

Gives the MIME protocol version used to encode the message, the current version being 1.0. Many browsers, unfortunately, send this even if the message is not MIME-compliant.

Other, Uncommon Message Property Header Fields

In principle, a client could also send the message property header fields allow, content-encoding, expires, last-modified, link, title, or URI. However, these are rarely used in a request header and so are not described here.

HTTP Response Header Field Specifications

The following is a list of currently implemented HTTP response headers. A more detailed list can be found in the references listed at the end of this chapter.

(A) Server and Connection Status Header Fields

These headers define properties about the server and about the client-server connection, such as the server capabilities, the date the message was sent, requests for authentication data required by the connection, and so on.

Date: date_time

Contains the time and date when the current object was assembled for transmission. The following example illustrates the format:

Thu, 03 Aug 1995 16:04:09 GMT

The time must be Greenwich Mean Time (GMT) to ensure a common time zone for all users and servers. Possible time formats are discussed at the end of this chapter.

Location: URL

Contains a URL to which the client should be redirected. This is returned by a server if the requested document was not found on the server, but the server knows the correct (moved) location of the resource. A Location header is included when a redirection HTTP status field (status 301 or 302) is returned.

Contains a comma-separated list of nonstandard (experimental) methods supported by the server. This header is not implemented on most current servers.

Retry-after: date_time (or seconds)

Contains a time and date (or a time in seconds) after which a client should retry to access a resource that was temporarily unavailable. This field is appropriate when the status header 503 (service unavailable) is being returned. It might be returned by a server or gateway program that is temporarily unable to comply with a request. Typical forms are:

Retry-after: Thursday, 10-Aug-95 12:23:12 GMT
Retry-after: 60

The latter indicating that the client should retry after a 60 second wait. Most browsers (and proxy servers) do not understand the retry-after field.

Server: program /version

Contains information about the server software from which the resource originated. The program and version information fields are separated by a slash.

Contains cookie data sent by the server. A browser that supports cookies will save these data to disk, and will return them to the server that originally deposited the data. The mechanism is discussed in detail in Chapter 10.

WWW-Authenticate: scheme scheme_message

Tells the client about the user authorization scheme the server wants to use. This is returned following any browser request that requires user authentication. Scheme gives the name of the authorization scheme (e.g. Basic ), while scheme_message gives data, related to the scheme, that is required by the browser..

(B) Message Properties Header Fields

These headers define specific properties of the message or resource being sent. If no message is sent, these fields will be absent.

Allow: method1, method2, ...

Contains a comma-separated list of HTTP methods supported by the resource. This must be returned if the status code 405 (HTTP method not allowed) is being returned. It can contain any supported method, including nonstandard ones supported by the server. In principle, the browser can then attempt to re-contact the server using one of the supported methods. This is not implemented by current browsers or servers.

Content-Encoding: encoding_type

Specifies the encoding type mechanism appropriate to the data. The only currently valid types are compress and gzip and their synonyms x-compress and x-gzip (the latter are obsolete, and are being phased out). You can only have one content-encoding type per header. This allows compressed files to be uncompressed on-the-fly by the client.

Content-language: lang

Gives the language of the message being sent to the client.

Content-length: length

Gives the length, in bytes, of the message being sent to the client.

Content-type: type/subtype ; parameters

Gives the MIME content-type of the message being sent to the client. The content-type can contain optional parameter fields, separated from the type/subtype by a semicolon. For example

Content-type: text/html; charset=ISO-10646-1

indicates that the message is an HTML document, written using the ISO 10646-1 character set. Parameter fields are ignored by most current browsers.

Indicates the version of the resource being sent. This is used in version control for document management purposes. It is implement by some version control systems, but is not implemented by most current browsers.

Indicates that the version of the resource from which the enclosed data (being sent by the client to the server) were derived. This is used in version control of collaboratively developed resources, and, under HTTP 1.1, is mandatory if data are being sent to the server using the PUT method. This field is not implemented on current browsers (which also do not support PUT).

Expires: date_time

Gives the time and date after which the information being sent should be considered invalid. This tells clients when to refresh data in their local cache. Proxy servers can use this field to determine when a cached copy of a document should be refreshed.

Last-modified: date_time

Gives the date and time that the document was last modified, here in the format Thu, 03 Aug 1995 16:02:27 GMT. As in the Date field, the date must be given in Greenwich Mean Time.

Link: link_information

This is similar to the HTML LINK element and defines relationships between the data being returned by the server and other resources. If derived for an HTML document, this field (or multiple fields) should contain the information from the LINK elements in the document. This allows the HTTP header to contain LINK information about a resource, and allows a client, using HEAD methods, to access information about the document that is useful for cataloguing, organizational, or indexing purposes. Link is not currently implemented.

MIME-version: version_number

See same entry in the preceding section, “HTTP Request Header Fields Specifications.”

Title: title

The title of the document. This should be identical to the contents of the document’s TITLE element.

URI: uri_of_resource

Contains a URL for the resource being sent—sometimes this is an alternate URL (as per the Location field). In general, the meaning of the URI header is not well defined, and it will be dropped in HTTP 1.1 in favor of other headers with better-defined meanings.