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 09:57:00 -0700
Message-Id: <199508161657.JAA11809@bert.amazon.com>
To: John Franks <john@math.nwu.edu>
Cc: Larry Masinter <masinter@parc.xerox.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
John Franks writes:
 > According to Larry Masinter:
 > > * A proxy or cache shouldn't save a document with a future
 > >   last-modified.
 > In the absence of another (cleaner) way to prevent caching this will
 > become the de facto way for a server to tell a client (or proxy) not to cache.
 > This, in effect, overloads the Last-Modified header so that 
 > Last-Modified: <date in 2010>
 > means "please don't cache this document."  This is obscure and error prone.

I agree that it would be bad if people started deliberately using it
in this way.  The question is, what is the desired behavior?  The rule
I would favor is that you needn't compare the last-modified date to
the present date at all.  If on one request for a document you get
last-modified date X, and on the next you get X+1, then you know the
server is saying the document has been modified since the last
request.  That's the only relevant semantic.  GET if-modified since
should use the last claimed modification date when making a request. 

 > It would be much better to have a clean, explicit way for a server to request
 > that a document not be cached by a proxy or client.  The current draft spec
 > gives a way to make the request of proxies but not of clients.

What about Expires: <= now?

  I would be
 > happy with one request applying to both or separate requests.  I haven't
 > heard any argument for separate requests.
See my previous post regarding Pragma: no-cache, which, by your
reckoning, is, I guess, a third way to request no caching.

 > Someone asked why you would want to request that a document not be
 > cached by the client in an unshared cache.  There are lots of reasons.  Think
 > about the famous coffee pot.
 > There are also reasons that a request not to cache should be orthogonal to
 > the Expires: header.  The most important in my opinion is that not making
 > them orthogonal encourages munging the header in order to prevent caching.
 > Fictitious expire dates overloading this header are a bad idea.

The only possible interpretation (ok, to me, anyway) of an expiration
date is that after that date, if you try to look at the document
again, you have to refetch it.  Thus the primary purpose of expires is
to control caching in exactly this way. Why is this overloading?

 > reason is that a document can be *valid* for some period of time even
 > though a new request will give a different document.  Think of a price
 > quote made yesterday which will be honored until its expiration date,
 > but a new quote will have a different price.
Now trying to implement *that* at the protocol level really seems like
overloading to me.

 > John Franks

--Shel Kaphan
Received on Wednesday, 16 August 1995 10:01:23 UTC

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