Re: Formalizing Expires, Last-Modified, "data object"

Daniel W. Connolly <> writes:
> I suggest that the protocol be defined by the observable
> behaviour of correct servers (and clients). For
> example, the critical property of the Last-Modified and
> Expires information for a URI is that the server
> stipulates that it will serve the same entity for that URI
> (given the same Accept: headers) at all times between the
> Last-Modified time and the Expires time.

This is also how I first interpreted Expires -- as a server guarantee  
that the URI produces constant data up to the stated time.  However,  
I've been convinced now that the spec's interpretation -- as a client  
directive to discard the information after the given time -- is more  

The practical considerations are shown most clearly for servers that  
want to serve ephemeral documents, custom-produced for each client's  
request (note that even if the document itself is POST output, its  
inline images will still be obtained by ordinary GET requests, and so  
Expires still applies).

The server does not want to have to keep the custom document around  
after the requesting client has fetched it; on the other hand, the  
server does want the client to enjoy the document for the full  
intended life of the information it contains.  If Expires is  
interpreted as a server guarantee there is no way to communicate the  
(more important) intended life of the document to the client.

Paul Burchard	<>
``I'm still learning how to count backwards from infinity...''

Received on Sunday, 1 January 1995 13:31:10 UTC