[squid-dev] [RFC] ICAP external acl services

Alex Rousskov rousskov at measurement-factory.com
Mon Jun 20 14:40:24 UTC 2016


On 06/19/2016 12:53 PM, Eliezer Croitoru wrote:

> Alex mentioned long ago the idea\option to add an ICAP service as an
> external_acl helper.

Not quite. We could add a new kind of slow ACL that would be backed by
an adaptation service (ICAP or eCAP). This is similar to how an external
ACL is backed by an external ACL helper today, but the new ACL will not
depend on the external ACL interface.

The primary benefits of adding such support are:

1. the new ACL can make decisions based on the message body;
2. the new ACL can make custom decisions faster than an external ACL
   (provided eCAP is used and possibly optimized; ICAP would be slower);
3. message adaptation/modification at numerous new vectoring points.

Everything else is already covered by external ACLs: Today, one can
write an external ACL helper that communicates with an ICAP or even eCAP
service. No Squid changes are necessary for that. However, a solution
based on external ACL does not get the benefits listed above.

Supplying message bodies to ACLs and allowing ACLs to modify messages
would be very difficult to implement given the current Squid code.
Correct configuration would also be difficult. It is not clear to me
whether all that complexity is worth the benefits.


There is also a much simpler idea that only provides benefit #2: A new
[fast] ACL kind that is backed by an eCAP service that provides an
[instant] decision based on message headers. Such ACLs can be made
significantly faster than external ACLs (benefit #2) and do not require
significant code changes. They do not provide benefits #1 and #3.


> Also any ICAP implementation requires a more deep understanding of HTTP
> in general which has it’s own pros and cons.
> 
> The main benefit of an ICAP service as I see it is that it's not bound
> to squid or c++ compared to eCAP.

eCAP is not bound to Squid either -- eCAP modules can be used in any
host application that supports the eCAP API. Squid is the only [popular]
open source eCAP host application right now, but that does not bind eCAP
adapters to Squid.


HTH,

Alex.



More information about the squid-dev mailing list