- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 06 Sep 95 13:28:20 MDT
- To: John Franks <john@math.nwu.edu>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Am I the only one who finds it extremely counter-intuitive to "ignore
the Expires when making replacement decisions" for a cache? I
strongly agree that "one might be tempted to toss resources out of the
cache that had expired a long time ago" and I would suggest that
adopting a semantics for the Expires header where the date has nothing
to do with whether or not a document can be removed from the cache
is inviting immense confusion.
I think you find this counter-intuitive because you are trying to use
the same information both for controlling what objects can be served
from the cache without validation, and when objects are removed from
the cache.
The first issue ("when does the cache have to validate with the server")
is a correctness issue. The HTTP protocol MUST specify the rules here,
because this involves an agreement between server and cache about the
mechanism for consistency. Expiration time is clearly an aspect of
these rules.
The second issue ("when does the cache manager remove an object from
the cache") is a policy issue. No matter what the cache manager does
for a replacement policy, correctness is not at stake. Performance
will, of course, depend strongly on the approach taken. However,
we really don't know what the right approach is, and so I do not
believe that the HTTP spec should demand a particular replacement
policy. After all, the spec cannot demand a particular minimum
cache size, so mandating a replacement policy in an attempt to
achieve some sort of performance goal is pointless. We can hope
that cache implementers and managers share our goal of reducing
latency and server loading, and leave it at that.
-Jeff
Received on Wednesday, 6 September 1995 13:36:43 UTC