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
