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
