RE: Expires and 'non-cacheable'

I don't dispute the meaning of 'non-cacheable'. However, I don't know that
it's the correct term to use here.

The use of non-cacheable here is internally inconsistent; Cache-Control:
no-cache means that the object must be revalidated (it's stale), not that it
can never enter the cache (that's no-store).

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.

Additionally, it contradicts:

13.2.1:
If an origin server wishes to force a semanticlly transparent cache to
validate every request, it MAY assign an explicit expiration time in the
past. This means that the response is always stale, and so the cache SHOULD
validate it vefore using it for subsequent requests.

13.4:
Unless specifically constrained by a cache-control (section 14.9) directive,
a caching system MAY always store a successful response (see section 13.8)
as a cache entry, MAY return it without validation if it is fresh, and MAY
return it after successful validation.










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

Received on Wednesday, 21 July 1999 17:54:51 UTC