Re: If-Modified-Since and forged dated

> 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