2011/10/19 Amos Jeffries <squid3@xxxxxxxxxxxxx>: > 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
