[squid-users] compression in Squid

[Amos Jeffries]

On 24/11/2016 11:06 a.m., reinerotto wrote:
> In the past, I used ziproxy together with squid for slow or expensive
> (mobile) point-to-point links.
> ziproxy compresses (gzip) data from the web, and sends it via squid over the
> slow/expensive link, usually also having a squid at the other end, serving
> the clients. 
> Very convenient, as practically all browsers directly handle the compressed
> data.
> 
> Now, the question: Where is the benefit of using Transfere-Encoding here ?
> 

* You would no longer need the ziproxy, and

* other middleware (ie AV scanner on client machine) can safely
decompress without having to do the whole dance with other headers
(ETag, Content-Type, Vary, etc.), and

* ETag, revalidation, Range requests works with same values for both
encoded and non-encoded versions of the object response without having
to cache multiple copies, and

* can be translated fairly easily to Content-Encoding for the final hop
(if the above ETag/Range things dont matter).

* browsers only support deflate, gzip and maybe sdch. Proxy<->proxy is
not tied to those and can use any form of compression that you find
works better without having to wait for them to become popular.

Yes the benefits of T-E over C-E are relatively few. That is part of why
its not a majory popular feature already.

Amos