- From: John Franks <john@math.nwu.edu>
- Date: Wed, 16 Aug 1995 09:59:30 -0500 (CDT)
- 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