On Sun, 13 Feb 2005, Tomasz Chmielewski wrote:
Other things Squid won't do:
- request and download a compressed content and then forward it uncompressed to a program that don't support gzip/deflate (e.g. wget),
Correct.
- when serving from a cache, it will not compress content when client requests it - but it would not matter on LAN anyway (it would only matter when Squid and the client are connected via a slow link).
Correct.
Also applies on cache misses.
What will happen if Squid caches some compressed html document (because the web server allowed to), and then this same page would be requested by a gzip/deflate-uncompatible browser?
Provided the web server sent a proper Vary header nothing bad will happen.
If the web server does not comply with the HTTP specifications and does not send Vary header on negotiated content then bad things will happen, but this is a concious decision by the web server admin and outside of your scope.
Squid will have to download this document once again, right?
Yes, but the gzipped variant will still be cached.
It is also worth noticing that the cache<->websever Vary negotiation isn't very efficient, and the way it is implemented in Squid-2.5 will cause quite many copies to be cached. There is a etag branch on devel.squid-cache.org which enhances this, but it is somewhat experimental and also many web servers is known to not following the HTTP specifications of the ETag and Vary headers making proper caching of this kind of negotiated content fail miserably (mod_gzip older than about a year or so, and there is a lot of other broken but not as widespread web server software out there)..
The design goals for Squid-3 in how this kind of content should be handled proper was defined at the code sprint before christmas, but it will take some time before this gets implemented.
Regards Henrik
