W3C home > Mailing lists > Public > http-caching-historical@w3.org > January 1996

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

From: David W. Morris <dwm@shell.portal.com>
Date: Tue, 9 Jan 1996 23:36:18 -0800 (PST)
To: Shel Kaphan <sjk@amazon.com>
Cc: Jeffrey Mogul <mogul@pa.dec.com>, Koen Holtman <koen@win.tue.nl>, http-caching@pa.dec.com
Message-Id: <Pine.SUN.3.90.960109232751.26917D-100000@jobe.shell.portal.com>

On Tue, 9 Jan 1996, Shel Kaphan wrote:

> Jeffrey Mogul writes:
>  > Aside from this confusion (which I'll take full blame for), Koen and
>  > I clearly agree that some maximum freshness lifetime needs to be
>  > imposed in the absence of a server-supplied value.
>  > 
>  > -Jeff
> Hmm. I don't.  Here's how I see this going down: if a header is
> required, people who write servers will make sure there is one with
> some default value as set up by default configuration parameters.  It
> is every bit as likely that server operators will fail to configure

Perhaps, I've forgotten a prior comment from Jeff, but I really don't
see much difference. I don't see Jeff insisting that the SERVER
provide the maximum freshness value, only that in the absence 
of one from the server, one must be specified. I read that to
mean the protocol should set one.

Someone made the argument that content providers or their managment
really need to know the fallback for how long a no longer current
document will be served by a cache.  When the freshness expires,
a single GET I-M-S either gets a new copy, or explictly or
implicilty resets the freshness interval.  Along with other 
considerations, this insures that a HTTP 1.0 server when moving
to HTTP 1.1 knows what its vulnerability is for stale cached copies.

Dave Morris
Received on Wednesday, 10 January 1996 07:48:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC