14.19 Date

   The Date general-header field 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.1.

          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 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
   MUST include a Date header field in all responses. 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 recipient if the message will be
   cached by that recipient or gatewayed via a protocol which requires a
   Date.







Fielding, et. al.           Standards Track                   [Page 116]

RFC 2068                        HTTP/1.1                    January 1997


   In theory, the date SHOULD represent the moment just before the
   entity is generated. In practice, the date can be generated at any
   time during the message origination without affecting its semantic
   value.

   The format of the Date is an absolute date and time as defined by
   HTTP-date in section 3.3; it MUST be sent in RFC1123 [8]-date format.

14.20 ETag

   The ETag entity-header field defines the entity tag for the
   associated entity. The headers used with entity tags are described in
   sections 14.20, 14.25, 14.26 and 14.43. The entity tag may be used
   for comparison with other entities from the same resource (see
   section 13.3.2).

         ETag = "ETag" ":" entity-tag

   Examples:

         ETag: "xyzzy"
         ETag: W/"xyzzy"
         ETag: ""

14.21 Expires

   The Expires entity-header field gives the date/time after which the
   response should be considered stale. A stale cache entry may not
   normally be returned by a cache (either a proxy cache or an user
   agent cache) unless it is first validated with the origin server (or
   with an intermediate cache that has a fresh copy of the entity). See
   section 13.2 for further discussion of the expiration model.

   The presence of an Expires field does not imply that the original
   resource will change or cease to exist at, before, or after that
   time.

   The format is an absolute date and time as defined by HTTP-date in
   section 3.3; it MUST be in RFC1123-date format:

         Expires = "Expires" ":" HTTP-date










Fielding, et. al.           Standards Track                   [Page 117]

RFC 2068                        HTTP/1.1                    January 1997


   An example of its use is

         Expires: Thu, 01 Dec 1994 16:00:00 GMT

     Note: if a response includes a Cache-Control field with the max-age
     directive, that directive overrides the Expires field.

   HTTP/1.1 clients and caches MUST treat other invalid date formats,
   especially including the value "0", as in the past (i.e., "already
   expired").

   To mark a response as "already expired," an origin server should use
   an Expires date that is equal to the Date header value. (See the
   rules for expiration calculations in section 13.2.4.)

   To mark a response as "never expires," an origin server should use an
   Expires date approximately one year from the time the response is
   sent.  HTTP/1.1 servers should not send Expires dates more than one
   year in the future.

   The presence of an Expires header field with a date value of some
   time in the future on an response that otherwise would by default be
   non-cacheable indicates that the response is cachable, unless
   indicated otherwise by a Cache-Control header field (section 14.9).