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

Re: If-Modified-Since and forged dated

From: Larry Masinter <masinter@parc.xerox.com>
Date: Wed, 16 Aug 1995 10:20:11 PDT
To: john@math.nwu.edu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <95Aug16.102012pdt.2763@golden.parc.xerox.com>
> Last-Modified: <date in 2010>

> means "please don't cache this document."  This is obscure and error prone.

No, Last-Modified: <date in 2010> means "I am broken, please notify my
webmaster to fix my clock". (Unless it's already 2010, I suppose.) 

I don't think we can possibly design a protocol that can resist the
determined attempts to abuse it, and I don't think we should.

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

As you point out, 'Expires' is the right way to handle this.

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

Why are such 'expires' dates fictitious? Why do you think people would
not overload 'Expires' but would overload 'Last-Modified'.

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

This is a nice thought experiment, but I'm baffled about how you
expect caches to behave in such a situation other than they would with
a straightforward application of 'Last-Modified' (date quote was made)
and 'Expires' (date when quote is no longer valid).

Besides, none of this has to do with adding a 'size' or 'length'
attribute, which was the original proposal that started this thread.
Received on Wednesday, 16 August 1995 10:21:59 UTC

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