Re: If-Modified-Since enhancement

"Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 22 Mar 1994 12:03:43 --100
Message-id: <9403220300.aa29856@paris.ics.uci.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: fielding@simplon.ICS.UCI.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: If-Modified-Since enhancement 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1899
Ari said:

> How about saying:
> 
>   Response headers are as if the client had originally sent a HEAD
>   request, but not all the headers need to be present, only the ones
>   that make sense in this context.  That means all the headers that
>   are relevant to cache managers, like Expires: and Date:.
> 
>   The purpose of this feature is that the server can upload a new expiry
>   date and other necessary metainformation to the requesting client
>   (often a caching proxy). This is to allow fast update of caches.

That's much better, but I think I would phrase it slightly different. E.g.
(as extracted from http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTRESP.html)
-------------------------------------------
Not Modified 304

If the client has done a conditional GET and access is allowed,
but the document has not been modified since the date and time
specified in the If-Modified-Since field, the server responds with
a 304 status code and does not send the document body to the client. 

Response headers are as if the client had sent a HEAD request, but 
limited to only those headers which make sense in this context. This
means only headers that are relevant to cache managers and which may
have changed independently of the document's Last-modified date. 
Examples include Date, Server, and Expires.

The purpose of this feature is to allow efficient updates of local
cache information (including relevant metainformation) without requiring
the overhead of multiple HTTP requests (e.g. a HEAD followed by a GET)
and minimizing the transmittal of information already known by the
requesting client (usually a caching proxy).
-------------------------------------------

How's that?


...Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                   (fielding@ics.uci.edu)
    <A HREF="http://www.ics.uci.edu/dir/grad/Software/fielding">About Roy</A>