General Header Fields

There are several headers that are applicable for both request and response messages. These header fields apply only to the overall message being transmitted; they do not apply to the entity being transferred. The general header fields defined in RFC 2616 are as follows:

• The Cache-Control header field is used to specify directives that must be obeyed by all caching mechanisms along the request-response chain. The directives specify behavior intended to prevent caches from adversely interfering with the request or response. These directives typically override the default caching algorithms. Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.

• The Connection header field allows the sender to specify options that are desired for that particular connection and must not be communicated by proxies over further connections.

• The Date header field represents the date and time at which the message was originated. The field value is an HTTP-date, it must be sent in RFC 1123 date format. For example,

   Date: Sun, 9 Mar 2003 08:09:10 GMT 

• The Pragma header field is used to include implementation-specific directives that might apply to any recipient along the request-response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems may require that behavior be consistent with the directives. For example,

   Pragma: no-cache 

• The Trailer header field value indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer-coding. An HTTP/1.1 message should include a Trailer header field in a message using chunked transfer-coding with a nonempty trailer. Doing so allows the recipient to know which header fields to expect in the trailer.

• The Transfer-Encoding header field indicates what (if any) type of transformation has been applied to the message-body in order to safely transfer it between the sender and the recipient. This differs from the content-coding in that the transfer-coding is a property of the message, not of the entity. For example,

   Transfer-Encoding: chunked 

• The Upgrade header field allows the client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols. The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol.

• The Via header field must be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request-response chain.

• The Warning header field is used to carry additional information about the status or transformation of a message that might not be reflected in the message. This information is typically used to warn about a possible lack of semantic transparency from caching operations or transformations applied to the entity body of the message.