出于性能原因，我正在尝试将静态资源（css和javascript）作为缓存的gzip压缩文件提供。
页面在渲染时看起来是gzip，根据LiveHTTPHeaders将Content-Encoding正确设置为gzip，最重要的是，gzip压缩内容正好通过GIDZipTest页面（http://www.gidnetwork.com/tools/gzip-test.php）。以下是测试输出的示例：
压缩网页？是的
压缩类型？ gzip
大小，标记（字节）18,286
压缩大小（字节）4,427
压缩％75.8
----
ResponseHeaders
状态HTTP / 1.0 200确定
pragma no-cache cache-control 私人，最大年龄= 86500
截止日期：2009年8月24日星期四04:34:14 GMT
x-amz-acl public-read
content-type text / css
content-md5 hqJaTBS3OzDFet / QHsd + Qg ==
内容编码gzip
date Wed，19 Aug 2009 04:34:14 GMT
服务器 - 我的服务器 -
内容长度4427
内容编码标题以粗体显示，所有其他标题都符合预期。
测试页面还显示了未压缩的页面源代码，它总是与我希望它解压缩完全一样，我甚至尝试过复制和粘贴它以便由浏览器呈现，并且它可以工作，所以问题必须是在识别页面被压缩和解压缩的实际步骤中。
这不是特定于浏览器的。在FF，Webkit和IE中，这些gzip压缩文件未正确解压缩。我已经尝试了我能想到的一切，但我真的很难过。
答案 0 :(得分：4)
也许你还有其他东西第二次压缩文件，但仅适用于以接受编码方式列出的http 1.1客户端，就像大多数浏览器一样。 GIDZipTest正在发送http 1.0请求，并且gzipping到1.0客户端是有风险的，因为http 1.0没有客户端的接受编码字段来指示它们支持哪些编码，所以它对第二个压缩器有意义（如果有的话） ）不要gzip到1.0客户端。如果是这种情况，GIDZipTest将获得单个gzipped响应，而浏览器将获得双重gzipped（错误）响应。这只是一种可能性。很少见，但它确实发生了。
如果不是这样，你真的应该提供更多的信息，比如显示问题的页面的网址。
答案 1 :(得分：0)
我在过去几天调试过类似的问题。我项目中的所有html，css和js文件都是gzip'ed。它工作正常，直到firefox 3.5出现。 Firefox 3.0和IE 7 + 8没有任何问题。哦，Opera 9 + 10和Chrome也在编码上窒息。
症状是html和css文件被正确识别，只有js文件有问题。 Firebug给了我这个错误信息：
标签无效
内容编码：gzip \ n
我的解决方案是删除doctype。我尝试过宽松严格，但都不行。但我想知道适当的doctype是什么。