[Next] [Previous] [Up] [Top] [Full Contents] [Search]

4. HTTP Message

4.3 General Message Header Fields

There are a few header fields which have general applicability for both request and response messages, but which do not apply to the communicating parties or the entity being transferred. Although none of the General-Header fields are required, they are all strongly recommended where their use is appropriate, and should be understood by all future HTTP/1.0 clients and servers. These headers apply only to the message being transmitted.

General-Header	=	Date
	|	Forwarded
	|	Message-ID
	|	MIME-Version
	|	extension-header
Although additional general header fields may be implemented via the extension mechanism, applications which do not recognize those fields should treat them as Entity-Header fields.

4.3.1 Date

The Date header represents the date and time at which the message was originated, having the same semantics as orig-date in RFC 822.The field value is an HTTP-date, as described in Section 3.3.

Date	=	"Date" ":" HTTP-date
An example is

Date: Tue, 15 Nov 1994 08:12:31 GMT
If a message is received via direct connection with the user agent (in the case of requests) or the origin server (in the case of responses), then the default date can be assumed to be the current date at the receiving end. However, since the date--as it is believed by the origin--is important for evaluating cached responses, origin servers should always include a Date header. Clients should only send a Date header field in messages that include an entity body, as in the case of the PUT and POST requests, and even then it is optional. A received message which does not have a Date header field should be assigned one by the receiver if and only if the message will be cached by that receiver or gatewayed via a protocol which requires a Date.

Only one Date header field is allowed per message. In theory, the date should represent the moment just before the status/request-line is generated (i.e. the time at which the originator made the determination of what the request/response should be). In practice, the date can be generated at any time during the message origination without affecting its semantic value.

Note
An earlier version of this document incorrectly specified that this field should contain the creation date of the enclosed Entity-Body. This has been changed to reflect actual (and proper) usage.

4.3.2 Forwarded

The Forwarded header is to be used by proxies to indicate the intermediate steps between the user agent and the server (on requests) and between the origin server and the client (on responses). It is analogous to the "Received" field of RFC 822 and is intended to be used for tracing transport problems and avoiding request loops.

Forwarded	=	"Forwarded" ":" "by" URI [ "(" product ")" ]
		[ "for" FQDN ]
FQDN	=	<Fully-Qualified Domain Name>
For example, a message could be sent from a client on ptsun00.cern.ch to a server at www.ics.uci.edu port 80, via an intermediate HTTP proxy at info.cern.ch port 8000. The request received by the server at www.ics.uci.edu would then have the following Forwarded header field:

Forwarded: by http://info.cern.ch:8000/ for ptsun00.cern.ch
Multiple Forwarded header fields are allowed and should represent each proxy that has forwarded the message. It is strongly recommended that proxies used as a portal through a network firewall do not, by default, send out information about the internal hosts within the firewall region. This information should only be propagated if explicitly enabled. If not enabled, the for token and FQDN should not be included in the field value.

4.3.3 Message-ID

The Message-ID field in HTTP is identical to that used by Internet Mail and USENET messages, as defined in [11]. That is, it gives the message a single, unique identifier which can be used for identifying the message (not its contents) for "much longer" than the expected lifetime of that message. 

Message-ID	=	"Message-ID" ":" "<" addr-spec ">"
addr-spec	=	<as defined in RFC 822 [8]>
Although it is not required, the addr-spec format typically used within a Message-ID consists of a string that is unique at the originator's machine, followed by the required "@" character and the fully-qualified domain name of that machine. An example is

Message-ID: <9411151630.4256@info.cern.ch>
which is composed using the time, date and process-ID on the host info.cern.ch. However, this is only one of many possible methods for generating a unique Message-ID and recipients of a message should consider the entire value opaque.

The Message-ID field is normally not generated by HTTP applications and is never required. It should only be generated by a gateway application when the message is being posted to some other protocol that desires a Message-ID. HTTP responses should only include a Message-ID header field when the entity being transferred already has one assigned to it (as in the case of resources that were originally posted via Internet Mail or USENET).

4.3.4 MIME-Version

HTTP is not a MIME-conformant protocol. However, HTTP/1.0 messages may include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message. Use of the MIME-Version header field should indicate that the message is in full compliance with the MIME protocol (as defined in [6]). Unfortunately, current versions of HTTP/1.0 clients and servers use this field indiscriminately, and thus receivers must not take it for granted that the message is indeed in full compliance with MIME. Gateways are responsible for ensuring this compliance (where possible) when exporting HTTP messages to strict MIME environments. Future HTTP/1.0 applications must only use MIME-Version when the message is intended to be MIME-conformant.

MIME-Version	=	"MIME-Version" ":" 1*DIGIT "." 1*DIGIT
MIME version "1.0" is the default for use in HTTP/1.0. However, HTTP/1.0 message parsing and semantics are defined by this document and not the MIME specification.

T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen - 12 MAR 95

[Next] [Previous] [Up] [Top] [Full Contents] [Search]

Generated with CERN WebMaker