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
