Re: [squid-users] How to filter response in squid-3.1.x?

2011/10/19 Amos Jeffries <squid3_at_treenet.co.nz>:
> On Wed, 19 Oct 2011 05:15:22 +0800, Kaiwang Chen wrote:
>>
>> After a few investigation, I found the statement from
>> http://www.squid-cache.org/Doc/config/ecap_service/:
>>        vectoring_point =
>> reqmod_precache|reqmod_postcache|respmod_precache|respmod_postcache
>>                This specifies at which point of transaction processing the
>>                eCAP service should be activated. *_postcache
>> vectoring points
>>                are not yet supported.
>>
>> Also in http://wiki.squid-cache.org/Features/ICAP, similiar statement
>> was found:
>> Pre-cache REQMOD and RESPMOD vectoring points are supported
>>
>> Notice 6.1 Vectoring points from rfc5703 suggests 4 classess of
>> different adaption. I guess the above statemets is class 1, client
>> requests "on its way into the cache", and class 3, responses "on its
>> way into the cache"? A positive answer might be really bad news for
>> me, since I am looking for class 4,  client-specific responses coming
>> from the surrogate.. Would anyone please make me clear?
>
> Sort of.
>
> In Squid there are several mangling interfaces which the request goes
> through (URL rewrite, ESI etc). The ICAP/eCAP adaptation is the first layer.
> This means:
>  * "pre-cache REQMOD" is request received from client before any other local
> alterations are done. Some minor normalisation is performed during parsing
> but that is all. The adaptation producing a reply will prevent any other
> modifications being done. The reply gets sent straight back to the client
> (and not cached).
>
>  * "pre-cache RESPMOD" is responses coming from the server. Again with only
> minor parser normalizations. Caching here is determined by the output HTTP
> headers of the adaptation step. So you can at the adaptation step add
> client-specific things and strip away the cacheability of the response.
>
>
> To only change the HTTP headers, there are some tricks you can do with the
> "must-revalidate" and/or "proxy-revalidate" cache control. These controls
> causes the surrogate to contact the origin web server on every request. The
> origin can send back new headers on a 304 not-modified response. Meaning the
> headers get changed per-response, but the cached body gets sent only when
> actually changed. Retaining most of the bandwidth and performance benefits
> of caching.

So, the possible solution could be injecting a "Cache-Control:
must-revalidate" header by some eCap reqmod_precache service, then
Squid will revalidate the response on every request carrying new
request headers, then the origin server has its chance to set new
response headers? A little counter-intuitive workaround for class 4
adaption. Not perfect, since revalidate only occurs only when the
response is stale, while what I am looking for is adapting every
response before it leaves Squid for the client. 'Cache-Control:
max-age=0' will force revalidation every response, though.

I also chance read ESI which really resembles class 4 adaption with
limited capability that only modifies response body. Looks like it is
incapable of doing custom complex calculation. So Squid does not
support class 4 adaption in general? Any other alternative?

>
>  NP: this trick with 304 is only possible for headers which do not update
> headers with details about the particular body object. ie you can use it for
> altering Cookie values per-request, but not for changing the apparent
> Content-Encoding from gzip to deflate. For things affecting the body you use
> the normal 200 response and send the updated body as well.

Sure.

BTW, I tried the gzip compression adapter from
http://code.google.com/p/squid-ecap-gzip/, and found that after a
request carrying "Accept-Encoding: gzip", Squid always passes back
gzip'ed response to the client, even it no longer carries that header,
because the object is not modified. A request without gzip support and
with 'Cache-Control: no-cache' refreshes the cache to be always
returning plain text responses. Does it imply that Squid only caches
one copy of response, rather than one per each enconding? How to make
it serve other encoding different from the cached one?

>
> HTH
>
> Amos
>
>

Thanks,
Kaiwang
Received on Wed Oct 19 2011 - 16:39:41 MDT