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

Re: If-Modified-Since and forged dated

From: John Franks <john@math.nwu.edu>
Date: Wed, 16 Aug 1995 09:59:30 -0500 (CDT)
Message-Id: <199508161459.JAA04988@hopf.math.nwu.edu>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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.
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.  I would be
happy with one request applying to both or separate requests.  I haven't
heard any argument for separate requests.

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.  Another
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.

John Franks
Received on Wednesday, 16 August 1995 08:00:38 UTC

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