- 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
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. Etc. Dave Morris
Received on Wednesday, 10 January 1996 07:48:33 UTC