Content-Type: text/html

   Further discussion of methods for identifying the media type of an
   entity is provided in Section 7.2.1.

10.6  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.

       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
   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 POST request, 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.

   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.

      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)




 
RFC 1945                        HTTP/1.0                        May 1996


      usage.

10.7  Expires

   The Expires entity-header field gives the date/time after which the
   entity should be considered stale. This allows information providers
   to suggest the volatility of the resource, or a date after which the
   information may no longer be valid. Applications must not cache this
   entity beyond the date given. 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. However, information providers that
   know or even suspect that a resource will change by a certain date
   should include an Expires header with that date. The format is an
   absolute date and time as defined by HTTP-date in Section 3.3.

       Expires        = "Expires" ":" HTTP-date

   An example of its use is

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

   If the date given is equal to or earlier than the value of the Date
   header, the recipient must not cache the enclosed entity. If a
   resource is dynamic by nature, as is the case with many data-
   producing processes, entities from that resource should be given an
   appropriate Expires value which reflects that dynamism.

   The Expires field cannot be used to force a user agent to refresh its
   display or reload a resource; its semantics apply only to caching
   mechanisms, and such mechanisms need only check a resource's
   expiration status when a new request for that resource is initiated.

   User agents often have history mechanisms, such as "Back" buttons and
   history lists, which can be used to redisplay an entity retrieved
   earlier in a session. By default, the Expires field does not apply to
   history mechanisms. If the entity is still in storage, a history
   mechanism should display it even if the entity has expired, unless
   the user has specifically configured the agent to refresh expired
   history documents.

      Note: Applications are encouraged to be tolerant of bad or
      misinformed implementations of the Expires header. A value of zero
      (0) or an invalid date format should be considered equivalent to
      an "expires immediately." Although these values are not legitimate
      for HTTP/1.0, a robust implementation is always desirable.







 
RFC 1945                        HTTP/1.0                        May 1996