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

Re: Location Proposals

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Wed, 06 Sep 95 13:28:20 MDT
Message-Id: <9509062028.AA17029@acetes.pa.dec.com>
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.

Received on Wednesday, 6 September 1995 13:36:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC