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
Received on Sun Feb 13 2005 - 15:54:28 MST
This archive was generated by hypermail pre-2.1.9 : Tue Mar 01 2005 - 12:00:02 MST