10.8  From

   The From request-header field, if given, should contain an Internet
   e-mail address for the human user who controls the requesting user
   agent. The address should be machine-usable, as defined by mailbox in
   RFC 822 [7] (as updated by RFC 1123 [6]):

       From           = "From" ":" mailbox

   An example is:

       From: webmaster@w3.org

   This header field may be used for logging purposes and as a means for
   identifying the source of invalid or unwanted requests. It should not
   be used as an insecure form of access protection. The interpretation
   of this field is that the request is being performed on behalf of the
   person given, who accepts responsibility for the method performed. In
   particular, robot agents should include this header so that the
   person responsible for running the robot can be contacted if problems
   occur on the receiving end.

   The Internet e-mail address in this field may be separate from the
   Internet host which issued the request. For example, when a request
   is passed through a proxy, the original issuer's address should be
   used.

      Note: The client should not send the From header field without the
      user's approval, as it may conflict with the user's privacy
      interests or their site's security policy. It is strongly
      recommended that the user be able to disable, enable, and modify
      the value of this field at any time prior to a request.

10.9  If-Modified-Since

   The If-Modified-Since request-header field is used with the GET
   method to make it conditional: if the requested resource has not been
   modified since the time specified in this field, a copy of the
   resource will not be returned from the server; instead, a 304 (not
   modified) response will be returned without any Entity-Body.

       If-Modified-Since = "If-Modified-Since" ":" HTTP-date

   An example of the field is:

       If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT






 
RFC 1945                        HTTP/1.0                        May 1996


   A conditional GET method requests that the identified resource be
   transferred only if it has been modified since the date given by the
   If-Modified-Since header. The algorithm for determining this includes
   the following cases:

      a) If the request would normally result in anything other than
         a 200 (ok) status, or if the passed If-Modified-Since date
         is invalid, the response is exactly the same as for a
         normal GET. A date which is later than the server's current
         time is invalid.

      b) If the resource has been modified since the
         If-Modified-Since date, the response is exactly the same as
         for a normal GET.

      c) If the resource has not been modified since a valid
         If-Modified-Since date, the server shall return a 304 (not
         modified) response.

   The purpose of this feature is to allow efficient updates of cached
   information with a minimum amount of transaction overhead.

10.10  Last-Modified

   The Last-Modified entity-header field indicates the date and time at
   which the sender believes the resource was last modified. The exact
   semantics of this field are defined in terms of how the recipient
   should interpret it:  if the recipient has a copy of this resource
   which is older than the date given by the Last-Modified field, that
   copy should be considered stale.

       Last-Modified  = "Last-Modified" ":" HTTP-date

   An example of its use is

       Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

   The exact meaning of this header field depends on the implementation
   of the sender and the nature of the original resource. For files, it
   may be just the file system last-modified time. For entities with
   dynamically included parts, it may be the most recent of the set of
   last-modify times for its component parts. For database gateways, it