http://redbot.org/ should be able to confirm if this a problem... On 10/03/2010, at 4:56 PM, Amos Jeffries wrote: > Elli Albek wrote: >> Hi, >> I have squid in front of tomcat servers as reverse proxy. The origin >> servers return some files gzipped. I can confirm this by going to them >> directly with header >> Accept-Encoding: gzip,deflate >> Origin server returns: >> HTTP/1.1 200 OK >> Server: Apache-Coyote/1.1 >> Cache-Control: max-age=1801 >> Accept-Ranges: bytes >> ETag: W/"18267-1250213328000" >> Last-Modified: Fri, 14 Aug 2009 01:28:48 GMT >> Content-Type: text/css >> Content-Encoding: gzip >> Vary: Accept-Encoding >> Date: Wed, 10 Mar 2010 03:58:54 GMT >> Connection: close >> If I go to squid with the same header I get the uncompressed file: >> HTTP/1.0 200 OK >> Accept-Ranges: bytes >> Last-Modified: Fri, 14 Aug 2009 01:28:48 GMT >> Content-Type: text/css >> Content-Length: 18267 >> Server: Apache-Coyote/1.1 >> Cache-Control: max-age=1801 >> ETag: W/"18267-1250213328000" >> Date: Wed, 10 Mar 2010 04:38:40 GMT >> X-Cache: HIT from www... >> X-Cache-Lookup: HIT from www... >> Via: 1.1 www...:80 (squid/2.7.STABLE6) >> Connection: keep-alive >> The only squid configuration is reverse proxy ACL for origin servers >> and the domains they map to, there is nothing specific to compression >> or headers in general. This is using the default tomcat connectors >> that support compression. >> Any ideas? > > It looks like the inconsistent vary problem. Do a bit more of a scan requesting the same URL this time checking variations of Accept header content. ( "*", "*/*", "gzip", "deflate", "identity" ). > > If any of the responses come back without "Vary: Accept-Encoding" that needs to be fixed. > > Amos > -- > Please be using > Current Stable Squid 2.7.STABLE7 or 3.0.STABLE24 > Current Beta Squid 3.1.0.17 -- Mark Nottingham mnot@xxxxxxxxxxxxx
