Reputation: 5084
I'm attempting to serve static resources (css and javascript) as cached gzipped files for performance reasons.
The pages look gzipped when rendered, the Content-Encoding is correctly set to gzip according to LiveHTTPHeaders, and most importantly, the gzipped content is passing the GIDZipTest page (http://www.gidnetwork.com/tools/gzip-test.php) just fine. Here's an example of the output from the test:
Web page compressed? Yes
Compression type? gzip
Size, Markup (bytes) 18,286
Size Compressed (bytes) 4,427
Compression % 75.8
----
ResponseHeaders
status HTTP/1.0 200 OK
pragma no-cache cache-control private, max-age=86500
expires Mon, 24 Aug 2009 04:34:14 GMT
x-amz-acl public-read
content-type text/css
content-md5 hqJaTBS3OzDFet/QHsd+ Qg==
content-encoding gzip
date Wed, 19 Aug 2009 04:34:14 GMT
server -- my server --
content-length 4427
The content-encoding header is in bold, and all the other headers are as expected.
The test page also shows the uncompressed page source, and it's always exactly as I'd expect it to be uncompressed, and I've even tried copying and pasting it to be rendered by the browser, and it works, so the problem must be in the actual step of recognizing that the page is gzipped and unzipping it.
And this isn't browser-specific. In FF, Webkit, and IE, these gzipped files are not being unzipped correctly. I've tried everything I can think of, but am genuinely stumped.
Upvotes: 1
Views: 2036
Reputation:
I've debugged a similar problem over the last couple of days. All html, css and js files in my project are gzip'ed. It worked fine until firefox 3.5 came along. Firefox 3.0 and IE 7+8 didn't have any issues. Oh and Opera 9+10 and Chrome choked on the encoding as well.
The symptoms were html and css files are correctly recognized, only js files had the problem. Firebug gives me this error message:
Invalid Label
Content-Encoding: gzip\n
The solution for me was to remove the doctype. I've tried loose and strict and neither works. But i would like to know what the proper doctype is.
Upvotes: 0
Reputation: 2174
Maybe you have something else gzipping the file a second time, but only for http 1.1 clients that list it in accept-encoding, like most browsers. GIDZipTest is sending http 1.0 requests, and gzipping to 1.0 clients is risky because http 1.0 doesn't have an accept-encoding field for clients to indicate which encodings they support, so it'd make sense for the second compressor (if there is one) to not gzip to 1.0 clients. If that's the case, GIDZipTest would get a single-gzipped response while browsers would get a double-gzipped (bad) response. That's just one possibility though. Rare, but it happens.
If that's not it, you really should give more information, like a url to a page exhibiting the problem.
Upvotes: 4