[squid-users] Squid with ICAP filter?

[Mike Summers]

Thanks Alex.

You are correct, the message bodies are compressed (gzip). For reasons
unknown the ICAP service can't or won't deal with compressed data. Also
correct, the ICAP service is a black box for us.

Much thanks for the response, it gives us a place to start.

--Mike


On Thu, Mar 17, 2016 at 2:47 PM, Alex Rousskov <
rousskov at measurement-factory.com> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160317/bd50f933/attachment-0001.html>