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_at_yahoo-inc.comReceived on Wed Mar 10 2010 - 06:28:36 MST
This archive was generated by hypermail 2.2.0 : Wed Mar 10 2010 - 12:00:03 MST