Re: dropping headers in parse mode

On Monday 23 June 2003 21.30, David Nicklay wrote:

> Agreed. That was only a quick and dirty hack for some well known
> backend servers (in reverse proxy mode with accel_single_host on).
> I would like to find a clean way of doing this, or alternatively
> for Squid to recognize what the Cache-Control line is actually
> intending to be done. I will see if I can do either.

To make Cache-Control: no-cache=... behave like expected requires a
fair bit of work as the cache revalidation in Squid is flawed and
does not update reply headers on cached objects. However, as an
approximation it can be processed the same as private=... until cache
revalidations can be corrected proper. The RFC is also slightly
unclear on the effect of cache revalidation and headers marked with
no-cache.

To make Cache-Control: private=... behave like expected should be
pretty trivial. This is sort of a Connection: header for cache hits
only, indicating headers which must not be given to clients on later
cache hits. Optimally headers marked as private should not even be
stored, but this is not a strict requirement from a functionality
perspective.

The no-cache=... and private=... response cache-control parameters is
different from their plain versions without = in that with an = they
only apply to the listed headers but without = they apply to the
whole response.

To add knobs to Squid for selectively overriding Cache-Control
response parameters is a somewhat bigger job as these are spread out
little here and there in the source, but adding a filter mode which
completely filters out unwanted cache-control parameters should not
be too hard as demonstrated.

Regards
Henrik
Received on Mon Jun 23 2003 - 17:21:34 MDT