Re: [PATCH] Cache-Control overwriting hack

> Hi,
>
> This is a patch of probably limited utility, but I'll send it out
> anyway and leave it for you folks to decide :) It was written against
> 2.7STABLE6 but patches cleanly into HEAD.
>
> The purpose of this patch is to support the use of an "alternate"
> Cache-Control header in reverse-proxy environments. The patch consists
> of a new config directive, replace_client_cc, and code in
> client_side.c that is called if that config option is enabled.
>
> The new code then looks for the existence of a header titled "Client-
> Cache-Control" which should contain syntax similar to that of a normal
> Cache-Control header. When present, Squid will delete the existing
> Cache-Control header if it exists, replace it with the contents of
> Client-Cache-Control, then delete the Client-Cache-Control header.
>
> So, the end result is that you have one Cache-Control header that
> squid pays attention to, and then a completely different one that
> client browsers will see.
>
> A couple TODOs on this if folks agree it's worthwhile:
>
> 1. Change the config option to a named header, eliminating the need to
> hard-code Client-Cache-Control (at the cost of using
> httpHeaderFindByName() instead of httpHeaderGetList() which seems much
> more costly CPU-wise).
>
> 2. Allow for some method by which the original Cache-Control header
> can be preserved for diag purposes (maybe add in as X-Original-Cache-
> Control?)
>
> Feedback appreciated, etc...
>
> -C

Oh dear. Why are you thinking this is necessary?

AFAIK, header_access and header_replace even in Squid-2 are supposed to do
exactly that. If not that is a bug which needs to be fixed.

Amos
Received on Mon May 04 2009 - 23:29:18 MDT