Re: Squid3 with multiple ICAP Services

On Tue, 2007-09-25 at 13:08 -0400, Richard Bishop wrote:

> Between sending email my and receiving your I have been having a play
> around with this idea. I've gotten to the point where I have multiple
> ICAP services being processed for REQMOD methods

Glad you made it work for your needs!

> though nothing for RESPMOD as yet. As I see it, REQMOD is somewhat
> simpler than RESPMOD since you're never going to be dealing with such
> massive amounts of data. A request is generally only going to be a
> few KBs (a few MB in the case of an HTTP POST), whereas RESPMOD could
> be anything (together with your points made below about pipelining).

FWIW, the modifications I had in mind would not depend on the vectoring
point. The same code should handle both REQMOD and RESPMOD. In fact, the
core client- and server-side code should not know that they are dealing
with multiple ICAP services (or load balancing them or anything else of
that kind).

> I would suggest that there should be an option to bypass particular
> services based on the results of earlier services - i.e. values of
> ICAP headers returned in the response. In the case of multiple
> chained virus scanners, this would mean that the presence of an
> X-Virus-Found after the first transaction (indicating the first
> scanner found a virus and rewrote the body), would then skip the other
> services since we then know this rewritten body to be clean.

It would be difficult to support a flexible decision making in
squid.conf (we need a better configuration/scripting language for that),
but we can try to support a few typical scenarios. Specific squid.conf
designs to address this need are very welcome!

> It is certainly pointless (and slow) to buffer data that could be
> piped straight into the next service and onto the client.

In some cases, buffering request bodies is impossible because they are
too large to be buffered in RAM (e.g., large PUT requests).

Alex.
Received on Tue Sep 25 2007 - 14:02:36 MDT