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

Re: Still trying to make sense of HTTP caching model

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Wed, 06 Sep 95 11:29:12 MDT
Message-Id: <9509061829.AA15907@acetes.pa.dec.com>
To: Shel Kaphan <sjk@amazon.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
    One thing I *do* hate about this is that "expires: <right now>" has
    problems because of clock skew, but otherwise that would seem to
    make more sense intuitively than "expires: yesterday".

You may want to look at the proposal I sent last month for using
the server's current date to de-skew Expiration times.  We may simply
want to make Date: mandatory for responses with an Expires: header.
If Date: > Expires:, then the meaning should be unambiguous.


 people have diametrically opposite ideas of what
is natural here.  I would point out that the "Expires: yesterday"
approach might be more likely to cause correct operation of existing
proxies, but I don't have specific evidence to back this up.

Paul writes:
    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.

That's a good point; the cache-manager's replacement policy is
in some sense entirely distinct from the rules for when a cached
object is considered valid, but perhaps one might find that
a replacement policy favoring unexpired objects over expired ones
would work better than simple LRU.  This, however, will take real-world
experimentation to decide, and the choice is one that can safely be
left unspecified in the HTTP specification (and should be left unspecified,
since we don't know the right answer).


P.S.: One point I neglected to cover yesterday: clearly, the ultimate
client should always have the option to tell any cache along the
path to reload from the ultimate server, in spite of any belief
the cache manager might have about the validity of its cached copy.
Received on Wednesday, 6 September 1995 11:38:24 UTC

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