Re: Cache behavior in the absence of a Fresh-until: header

Jeffrey Mogul:
>I'd prefer to use slightly different words, to be more precise:
>The protocol design should use *declarative* rather than *procedural*
>techniques whenever possible, since that tends to give the
>implementations more flexibility.

While I am all for declarative headers, I do't see much value in
insisting that the protocol design itself is expressed as much as
possible in declarative terms.  

There is a common trick to ensure that a procedural specification does
not limit the flexibility of an implementation: instead of saying that
the implementation must do X, say that the implementation must _act as
if_ it does X.

[....]
>    By all means state 'in the absence of a fresh-until time, the cache
>    may assume a default of 7days'  

Let me say again that I proposed an _upper limit_ of 7 days as the
result of the heuristical freshness computation of the cache: I did
not propose a default of 7 days.  That would not be very much better
than proposing a default of 0 days.  Also, I would be happy with much
higher upper limits, say 1 month.

>                                     -- the period of time should be
>    chosen to be in accord with the defaults in use by that currently
>    existing caches.
>
>Is this what HTTP/1.0 caches do: keep things for 7 days?  Or does
>the practice vary?  Any experts out there?

I believe the practice varies.  The CERN cache seems to have the
directive CacheRefreshInterval to specify such an upper bound.  The
documenattion file gives

 CacheRefreshInterval  *                            1 week

as an example, but our local CERN cache has 1 month configured for
this value.

>-Jeff

Koen.

Received on Wednesday, 10 January 1996 12:49:39 UTC