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

RE: Expires and 'non-cacheable'

From: David W. Morris <dwm@XPASC.COM>
Date: Wed, 21 Jul 1999 09:47:15 -0700 (PDT)
To: Scott Lawrence <lawrence@agranat.com>
cc: "Nottingham, Mark (Australia)" <mark_nottingham@exchange.au.ml.com>, http-wg@hplb.hpl.hp.com
Message-ID: <Pine.GSO.4.05.9907210941490.19209-100000@shell1>

On Wed, 21 Jul 1999, Scott Lawrence wrote:

> > From: Nottingham, Mark (Australia)
> > In 14.9.3,
> > [...]
> > Many HTTP/1.0 cache implementations will treat an Expires value
> > that is less
> > than or equal to the response Date value as being equivalent to the
> > Cache-Control response directive 'no-cache'. If an HTTP/1.1 cache receives
> > such a response, and the response does not include a Cache-Control header
> > field, it SHOULD consider the response to be non-cacheable in order to
> > retain compatibility with HTTP/1.0 servers.
> >
> > Would it be safe to assume 'non-cacheable' can be interpreted as 'stale'
> > here? (everything else says it is)
> I usually use 'stale' to mean something that it was ok to cache for some
> amount of time, but that time has passed, so it is no longer ok to use the
> cached copy.  'non-cacheable' means that it should not get into the cache at
> all.

I agree ... 'non-cacheable' is supposed to preclude any possibility that
the data would be found in a cache and in particular a disk cache where
it might be examined. 'non-cacheable' is supposed to mean that it would
never be valid for a caching proxy to return in response to a request.
No second guessing, ever.

Dave Morris
Received on Wednesday, 21 July 1999 17:50:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:33 UTC