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

[Amos Jeffries]

On 20/06/2016 6:53 a.m., Eliezer Croitoru wrote:
> Hey,
> 
>  
> 
> Alex mentioned long ago the idea\option to add an ICAP service as an
> external_acl helper.
> 

I suspect you misunderstood him. The two things are very differently
focused and the informational needs and limitations are equally different.

> I want to highlight my understanding of couple things about the subject.
> 
> Currently external_acl helpers are required to "decide" on an action based
> only on couple basic parts of the request.
> 
> It's not bad or wrong but ICAP can extend squid helpers assistance.
> 
> It can extend the decision to the brief request and response details.
> 

No. The decisions that ACLs participate in making for Squid are
completely orthoginal to ICAP.

ICAP can produce state changes in the transaction to cause the decision
process to go a different way to where it would go without ICAP. But it
cannot directly make the descision itself. The ICAP changed state still
has to be (re-)processed for those descisions at the point(s) Squid
needs them made.

>  
> 
> Alex mentioned at the time that ICAP services implements ACLs but in a form
> which the interface maybe was not designed for.

Yes.

> 
> I think that the ICAP services interface usage might be used a bit "off" to
> what it was designed for but it seems OK to me for many cases.

ICAP and eCAP are suitable for when modifications and descisions need to
include anythign in the payload.

ACLs (including external ACL) are suitable for decisions and
modifications only requiring HTTP and transport layer metadata.


> 
> 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 C++ either. At heart it is a library ABI
definition. Any module could in theory be built in another language - as
long as it presents the C++ symbolic eCAP ABI to Squid.
The only thing that is binding it at present is the fact that doing
cross-language ABI is difficult and the existing eCAP library is in C++.

> Means I like ICAP better and maybe since I have better luck with it.
> 

ICAP is like having root/admin privileges over the transaction. Of
course its more attractive than doing things in restricted targeted
ways. Even if all that is needed is a simple binary descision.

You have to choose if you actually need the complication of *CAP
overheads. Or would something much simpler be more suitable.

And I dont mean the ease of coding detail you seem to be focussing on.
But the x3 multiplier on CPU, socket, RAM resource and latency delays.
Doubling (or more) on latency is a big deal.

> 
> And to the actual implementation idea:
> 
> There are couple options on how an ICAP service should respond.
> 

Nope. There is pretty much just one. Fake request delivered to ICAP with
parameters as HTTP headers. Status of the reply delivered back
translated to OK/ERR values.

> I think that "OK" or "ERR" are good but a "DUNNO" ie use default action
> could be used.
> 
>  
> 
> I hope that you have comments to write about the subject.
> 
> Will it be good to add ICAP based external acl interfaces?

No it would be horribly complex.

> 
> Maybe it's too complex?
> 
> Are there any benefits to external_acl helpers over ICAP services?
> 

Simplicity. Speed. Flexibility.

And not having to teach admin a major compicated protocol just to script
a yes/no decision. The basic helper I/O protocol we have already seems
to be blowing some peoples minds.

Amos