Re: [squid-users] Squid-2.7 vary failure w/ non-encoded objects?

On lör, 2008-08-30 at 15:36 +0800, Adrian Chadd wrote:

> * Subsequent requests w/ or w/out Accept-Encoding: set will always
> return the non-compressed object

There is two possible reasons to this, both involving broken web servers

a) Some web servers forget to add Vary on the non-compressed variant,
thereby telling caches that the non-compressed variant is valid for any
kind or request, even those supporting compression.

b) Some web servers respond with the same ETag on both compressed and
non-compressed variants, thereby telling caches that there is no
difference (at octet level) between the two.

For 'a' there is no workaround other than fixing the web server to
respond proper.

For 'b' there is a workaround in squid.conf, but it only solves the
problem in your Squid and not any other caches out on the Internet so
you still need to fix your web server if this is the problem or it will
bite users quite bad (MSIE users behind proxies quite likely won't be
able to visit the site from time to time...)

> My uttterly conjecture based guess: should the origin server be
> returning non-compressed objects with the same Vary: headers?

Vary SHOULD always include the headers the web server have looked for
(even non-existing ones) while determining the kind of response.

> How are others' dealing with this in accelerator based setups?

The solution is to fix your web server. Can often be done by a simple
web server configuration change to properly set the Vary header, but for
some web servers an upgrade is needed.

Regards
Henrik