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
Attachment:
signature.asc
Description: This is a digitally signed message part
