Reasons why gzipped content might not be grokked by the browser

Question

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.

Answer 1

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.

Answer 2

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.