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@xxxxxxxxxxxxxxxxxxxxxxx> 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.
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
