On 10/4/17, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 09/30/2017 11:14 PM, Jeffrey Merkey wrote: >>> After reviewing this problem and all of the great technical >>> information folks provided, I have it working and I figured out the >>> best way to deal with this transparently allowing squid to remotely >>> spoof the server side with modified request headers. > > Overall, the above is _not_ the best way to deal with the encoding > problem. The overall best way is for your eCAP or ICAP service to decode > virgin and encode adapted message bodies as needed. That way, your Squid > does not mangle client requests to lie about accepted encodings and your > service can handle cases where the origin server sends encoded messages > regardless of the request Accept headers. > > Alex. > Hi Alex, great minds think alike. I came to the same conclusion about using that request header hackery and I have almost completed a c-icap service called "inflate" that ungzip's the data as part of an icap service chain. I already have incorporated gzip and deflate libs into the icap service , and I am now integrating brotli as well. The service is not fully completed but will be finished sometime this week. The code is stored as a branch at: https://github.com/jeffmerkey/icap/tree/inflate I will say this, the hack I discussed in the above thread with sending altered request headers for "accept-encoding:*;p=0" does seem to work in terms of spoofing remote servers into not sending compressed data, but I also noticed that not all servers on the internet respond to it correctly, and some web servers ignore it and send compressed gzip data anyway. I will post to the icap list a patch series which contains this "inflate" service module. Jeff _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
