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