Re: No-Cache: Squid vs RFC2616

must-revalidate (now) means that the object's freshness information must be
respected; caches shouldn't take liberties with stale objects (as they are
allowed to do).

no-cache is indeed a bad name for it, especially since it has different
meanings in requests vs. responses.

In this respect, Squid could be characterised as compliant (it won't cache
objects with no-cache inappropriately), but suboptimal (it could keep them
and just validate them).

On Fri, Mar 03, 2000 at 09:37:16AM -0700, Duane Wessels wrote:
>
>
> On Fri, 3 Mar 2000, Sandra Dykes wrote:
>
> >
> > The Squid FAQ (12.23) states Squid-2 does not cache a document
> > returned with the response header Cache-Control:No-Cache.
> >
> > However, RFC2616 (HTTP1.1), Section 14.9.1, specifies the no-cache directive
> > to mean "a cache MUST NOT use the response to satisfy a subsequent
> > request without successful revalidation with the origin server."
> > I take this to mean the response is cachable, but on a subsequent
> > request the cache need to send an IMS request to the origin server,
> > not necessarily refetch the object.
> >
> > Can anyone clarify this apparent discrepancy?
>
> There is no discrepancy. Since Squid does not cache the
> response, it is not going to be used "to satisfy a subsequent
> request ...."
>
> If you look at section 14.9.1 in RFC 2068 it says:
>
> no-cache
> Indicates that all or part of the response message MUST NOT be cached
> anywhere. This allows an origin server to prevent caching even by
> caches that have been configured to return stale responses to client
> requests.
>
> I have no idea why the RFC authors chose to make such a significant
> change between these two documents. I think it really sucks because
> the first version is quite clear, but the latter version confuses
> things. In RFC 2616 it seems that 'no-cache' becomes almost the same
> as 'must-revalidate'.
>
> Duane W.

-- 
Mark Nottingham, Senior Developer
Akamai Technologies (San Mateo, CA)