> Can anyone clarify what Cache-Control: headers various versions of squid
> (1.1 current vs. 1.2, mainly) support? From my own onsite testing, as well
> as with Jigsaw, it appears that Squid (and NetCache, for that matter)
> don't support:
>
> Cache-Control: public
> Cache-Control: must-revalidate
>
>
> from rev 4 of HTTP/1.1:
>
> public
> Indicates that the response is cachable by any cache, even if it would
> normally be non-cachable or cachable
> only within a non-shared cache. (See also Authorization, section 14.8, for
> additional details.)
> [14.8...]
> If the response includes the "public" cache-control directive, it MAY be
> returned in reply to any
> subsequent request.
>
> must-revalidate
> Because a cache MAY be configured to ignore a server's specified
> expiration time, and because a client
> request MAY include a max-stale directive (which has a similar effect),
> the protocol also includes a
> mechanism for the origin server to require revalidation of a cache entry
> on any subsequent use. When the
> must-revalidate directive is present in a response received by a cache,
> that cache MUST NOT use the
> entry after it becomes stale to respond to a subsequent request without
> first revalidating it with the origin
> server. (I.e., the cache MUST do an end-to-end revalidation every time,
> if, based solely on the origin server's
> Expires or max-age value, the cached response is stale.)
>
> I know that they are MAYs there, but it would be a Good Thing[tm] if
> authenticated content could be cached with force-revalidation of the
> headers.
>
> On another topic, does anyone have a patch for Squid that does something
> similar to NetCache's Cookie Cheats (force cache objects matching a regex,
> even if they have a cookie associated with them)?
>
> Regards,
>
>
>
> Mark Nottingham
> Internet Project Manager
> Merrill Lynch - Melbourne, Australia
>
Received on Tue Sep 08 1998 - 23:09:07 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:41:54 MST