[squid-dev] Fake CONNECT requests during SSL Bump

[Alex Rousskov]

On 09/26/2015 04:52 PM, Eliezer Croitoru wrote:

> if I will run some DB action inside an eCAP module it
> should be done in a very specific way to not block the whole squid
> process or to use an ICAP service instead.
> 
> I wanted to verify that I am right on the assumption.


You are correct:

* The ICAP client implementation in Squid does not block the whole Squid
process because communication is done using non-blocking socket I/O.
What happens on the other side of that ICAP connection depends on the
ICAP server implementation. Some ICAP servers never create threads, some
create a thread per transaction, some support a pool of threads, and
some let ICAP adapters decide how to handle each transaction.

* The eCAP client (a.k.a. "host") implementation has to block the whole
host process because it has to use regular C++ function calls. What
happens on the other side of that function call is the eCAP adapter
responsibility. If your adapter can return from all eCAP function calls
"fast", there is no need to worry (and you are saving a lot by not
having to go over a TCP connection). If you cannot answer some of the
host questions "immediately", then you have to implement an async eCAP
adapter that uses threads or other non-blocking mechanisms to shield the
host application from "slow" or "blocking" adapter code.


Cheers,

Alex.