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
