- From: Shel Kaphan <sjk@amazon.com>
- Date: Wed, 16 Aug 1995 13:39:43 -0700
- To: Balint Nagy Endre <bne@bne.ind.eunet.hu>
- Cc: Shel Kaphan <sjk@amazon.com>, http wg discussion <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Balint Nagy Endre writes: > Shel Kaphan writes: > > Shel Kaphan writes: > > > > > > Uh, never mind what I just said about future last-modified dates. > > > It might be OK for GET if-modified-since, but obviously fails for > > > plain GETs. > > > > > > --Shel > > > I retract this retraction. > > A proxy cache that cares at all about last-modified > > should always use GET if-modified-since once it has the document > > cached at all. > Except in the presence of the Pragma: no-cache in the request. > Unfortunately CERN HTTPD/3.0 uses GET if-modified-since and passes the pragma - > which in turn has no effect, and I can't force a cache refresh! > > Andrew. Yes, sure, I agree. Let me expand on my retracted retraction. Proxies should just use the claimed mod date on resources they fetch and use that date when doing GET if-modified-since afterwards. They may also, of course, want to occasionally just get a new copy of something. For example, one way to manage this is to keep track of the LOCAL time when a document was last fetched. The point is that the origin-server's claimed modification time should never be relevant to any proxy cache along the line, except as a stored "cookie"-like thing that can be passed back in GET if-modified-since. So if some origin server claims a document was modified on Stardate 7239.64, a proxy ought to just hold on to that, ignore what it means, and pass it back to the origin server when it does a GET if-modified-since. --Shel Kaphan
Received on Wednesday, 16 August 1995 13:45:48 UTC