[squid-users] Squid with ICAP filter?

[Alex Rousskov]

On 03/17/2016 12:25 PM, Mike Summers wrote:
> We have a situation where we need to filter compressed HTTP traffic
> through an ICAP service, logging failures (4xx) or passing the original
> compressed payload to it's target destination on 2xx.
> 
> Something like this:
> 
>   * Incoming compressed HTTP
>   * Decompress and forward to ICAP service
>   * Log and discard if ICAP service returns 4xx
>   * Send original, compressed payload to destination if ICAP returns 2xx
> 
> Is that an appropriate use for Squid? If so what sort of configuration
> commands would we use? We're not certain where to begin.

I do not know what you mean by "compressed HTTP". If compressed HTTP
means something like "HTTP where message bodies contain zipped or
gzipped content", then you can accomplish the above by sandwiching your
ICAP service between two eCAP services in a single adaptation chain.

  http://www.squid-cache.org/Doc/config/adaptation_service_chain/
  http://www.squid-cache.org/Doc/config/icap_service/
  http://www.squid-cache.org/Doc/config/ecap_service/

Without going into many necessary details, the overall scheme may work
similar to this:

 0. Squid receives "compressed" message M.z.

 1. eCAP decompression service gets message M.z from Squid,
    decompresses M.z body, and
    sends the decompressed message M back to Squid.

 2. Your ICAP service gets message M and either blocks or allows it.

 3. If message M was allowed in #2,
    eCAP compression service gets message M from Squid,
    compresses M body, and
    sends the compressed M.z back to Squid.

 4. Squid forwards M.z to the next hop.

The above can be done using standard eCAP/ICAP interfaces and squid.conf
directives without reinventing the wheel, provided your ICAP service is
compatible with Squid. Certain performance optimizations are possible
with more work (e.g., the eCAP services may cache and reuse the
compressed version of the message).

If you want to reinvent the wheel by writing an ICAP client, then you
can write a single eCAP or ICAP service that talks directly to your ICAP
service, without using Squid adaptation chains. From Squid point of
view, there will be just one eCAP or ICAP service doing everything.

Needless to say that adding decompression support to the original ICAP
service itself would be the fastest and simplest option (but it requires
modifying the existing ICAP service code which I am guessing you cannot
or do not want to do).


HTH,

Alex.