W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Location Proposals

From: Paul Leach <paulle@microsoft.com>
Date: Wed, 6 Sep 95 09:58:55 PDT
Message-Id: <9509061755.AA21461@netmail2.microsoft.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
John Franks says:
] According to Shel Kaphan:
] >
] > According to what Jeff Mogul just recently said, "expires:
] > <yesterday>" accomplishes this "conditional caching".  The cache is
] > allowed to serve an expired, cached document if it receives a 304
] > response on a conditional GET to re-fetch the document, but it would
] > definitely have to issue a new conditional GET on each request.
] > (Unless 304 is allowed to update header information, as I think Andrew
] > suggested).
] >
]
] Once again, "conditional caching" is an important request for the server
] to communicate to the proxy, but it has nothing to do with an expiration
] date.  Why force the proxy and client to parse a bogus date and
] compare it with the current date?  Why confuse proxy, client and server
] writers who assume Expires: <date> means the document expires on that
] date?
]
] A desire for conditional caching by the server belongs in a
] Cache-Control header.  Why not "Cache-Control: cache-conditionally"

Because the desired behavior falls out so easily from the handling of 
"Expires:".

Consider:
1. A correct agent (client or proxy with a cache) will never 
automatically service a request from the cache with an expired 
document. (Possible near exception -- when the origin server is down, 
and the user has been told that they can have a possibly out of date 
copy or no copy at all. But this is not the normal, automatic, case.)
2. A agent that wishes to be efficient will use GET If-Modified-Since 
to see if the cached copy of a requested resource can be used to 
satisfy the request, getting a new copy only if necessary.
3. A agent that wishes to be efficient will try to keep the items in 
its cache good for as long as possible, so it will update the 
meta-information on its cached copies from results of GET IMS (and 
possibly other methods, too, but I'll ignore that here).
4. A agent that wishes to be efficient will manage its cache by 
noticing how long it has been since a cached resource has satified a 
request, and remove the least likely to satisy future requests when 
space is needed for new resources.

Tagging a document with a very ancient "Expired:", when handled 
consistent with the above considerations, will almost completely 
automatically cause the behavior that has been asked for: you always 
get the latest copy, saving the cost of getting it from the server when 
the cached copy is still valid, even though there is no promise that it 
still is.  The only slightly "funny" thing is that the agent has to 
ignore the Expires when making replacement decisions, instead only 
considering the actual reference pattern and other info, such as 
Last-Modified; in the absence of knowledge of this usage style, one 
might be tempted to toss resources out of the cache that had expired a 
long time ago.

In fact, an ancient Expires isn't even really necessary. Servers that 
wish this behavior could always send out an Expires an hour or so in 
the past (or far enough to compensate for reasonable clock skew, beyond 
which the client is deemed to get what they deserve for having a bad 
clock). And it would "just work".

To add some other header to try and create this behavior will only 
result in there being two ways to do the same thing, one completely 
natural, and the other (IMHO) forced. The result will be confusion.

Paul
Received on Wednesday, 6 September 1995 10:02:41 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:31 EDT