Re: No-Cache: Squid vs RFC2616

From: Sandra Dykes <sdykes@dont-contact.us>
Date: Fri, 3 Mar 2000 12:41:38 -0600 (CST)

Thanks for info on how Squid works.

I think the difference between RFC2616 "no-cache" and "must-revalidate"
is that "must-revalidate" only requires revalidation is the object is stale,
and "no-cache" always requires revalidation (wonderful terminology).

BTW: I noticed that some content providers (read Web advertisers) change entity
tags every minute or so, despite the fact the object is unmodified.
When I re-request the object with the previous entity tag in the
request header, these servers return the object instead of a 304 Not Modified.

My understanding is this defeats caching.
For example, NLANR traces show a 1x1 grey GIF background image from
DoubleClick, RealMedia, and Netscape gets requested a lot, but
doesn't get cached.

Anyone else notice this or know why they do it?
 

>
> 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.
>
>
Received on Sat Mar 04 2000 - 03:36:17 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:51:53 MST