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