<div dir="ltr">Thanks Alex.<div><br></div><div>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.</div><div><br></div><div>Much thanks for the response, it gives us a place to start.</div><div><br></div><div>--Mike</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 17, 2016 at 2:47 PM, Alex Rousskov <span dir="ltr"><<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 03/17/2016 12:25 PM, Mike Summers wrote:<br>
> We have a situation where we need to filter compressed HTTP traffic<br>
> through an ICAP service, logging failures (4xx) or passing the original<br>
> compressed payload to it's target destination on 2xx.<br>
><br>
> Something like this:<br>
><br>
</span>>   * Incoming compressed HTTP<br>
>   * Decompress and forward to ICAP service<br>
>   * Log and discard if ICAP service returns 4xx<br>
>   * Send original, compressed payload to destination if ICAP returns 2xx<br>
<span class="">><br>
> Is that an appropriate use for Squid? If so what sort of configuration<br>
> commands would we use? We're not certain where to begin.<br>
<br>
</span>I do not know what you mean by "compressed HTTP". If compressed HTTP<br>
means something like "HTTP where message bodies contain zipped or<br>
gzipped content", then you can accomplish the above by sandwiching your<br>
ICAP service between two eCAP services in a single adaptation chain.<br>
<br>
  <a href="http://www.squid-cache.org/Doc/config/adaptation_service_chain/" rel="noreferrer" target="_blank">http://www.squid-cache.org/Doc/config/adaptation_service_chain/</a><br>
  <a href="http://www.squid-cache.org/Doc/config/icap_service/" rel="noreferrer" target="_blank">http://www.squid-cache.org/Doc/config/icap_service/</a><br>
  <a href="http://www.squid-cache.org/Doc/config/ecap_service/" rel="noreferrer" target="_blank">http://www.squid-cache.org/Doc/config/ecap_service/</a><br>
<br>
Without going into many necessary details, the overall scheme may work<br>
similar to this:<br>
<br>
 0. Squid receives "compressed" message M.z.<br>
<br>
 1. eCAP decompression service gets message M.z from Squid,<br>
    decompresses M.z body, and<br>
    sends the decompressed message M back to Squid.<br>
<br>
 2. Your ICAP service gets message M and either blocks or allows it.<br>
<br>
 3. If message M was allowed in #2,<br>
    eCAP compression service gets message M from Squid,<br>
    compresses M body, and<br>
    sends the compressed M.z back to Squid.<br>
<br>
 4. Squid forwards M.z to the next hop.<br>
<br>
The above can be done using standard eCAP/ICAP interfaces and squid.conf<br>
directives without reinventing the wheel, provided your ICAP service is<br>
compatible with Squid. Certain performance optimizations are possible<br>
with more work (e.g., the eCAP services may cache and reuse the<br>
compressed version of the message).<br>
<br>
If you want to reinvent the wheel by writing an ICAP client, then you<br>
can write a single eCAP or ICAP service that talks directly to your ICAP<br>
service, without using Squid adaptation chains. From Squid point of<br>
view, there will be just one eCAP or ICAP service doing everything.<br>
<br>
Needless to say that adding decompression support to the original ICAP<br>
service itself would be the fastest and simplest option (but it requires<br>
modifying the existing ICAP service code which I am guessing you cannot<br>
or do not want to do).<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
<br>
</blockquote></div><br></div>