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

 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.

  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.

 HTH

 Amos
Received on Tue Oct 18 2011 - 22:48:08 MDT