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

Re: If-Modified-Since and forged dated

From: Shel Kaphan <sjk@amazon.com>
Date: Wed, 16 Aug 1995 13:39:43 -0700
Message-Id: <199508162039.NAA13989@bert.amazon.com>
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

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