javascript - 如果我们不支持 IE6，那么为 IE 压缩 Javascript 文件是否有意义？

Question

如果浏览器允许压缩，我正在使用 Django GZip 中间件 (django.middleware.gzip.GZipMiddleware) 来压缩内容。

如果浏览器是 Internet Explorer (MSIE) 并且内容是 Javascript 文件，则中间件不会对内容进行 gzip。我的理解是，在这种情况下，中间件会避免压缩，因为 IE6(没有补丁)存在 gzip 响应问题。

对于我们的网站，我们不支持 IE6，但支持 IE7 和 IE8。考虑到我们不支持 IE6，即使浏览器是 IE，我们最好还是 gzip 所有 javascript 文件吗？

如果是这样，压缩这些文件的最佳方法是什么？我们希望继续使用 Django 中间件模块进行 gzip。我们是否应该复制 gzip 中间件模块并编辑处理 IE 和 Javascript 的几行(这感觉就像我们违反了 DRY)？使用 Apache 进行 gzip 也是一种选择。

Answer 1

受 JS/CSS 上的 gzip 问题影响的 IE6 版本不再普遍流通(即使在当时也是少数情况)。 Netscape 4 已经消失很久了。

出于这个原因，我强烈建议删除所有现有的 User-Agent-sniffing gzip hacks。根据标准 HTTP/1.1，将压缩的 HTML/JS/CSS 发送到所有请求它的浏览器(使用 Accept-Encoding)。

if "msie" in request.META.get('HTTP_USER_AGENT', '').lower():

哦，亲爱的。即使按照 UA 嗅探的令人沮丧的标准来看，这也是一个非常糟糕的测试。不检查它实际上是 MSIE 位于字符串中的正确位置(而不是所有尾随位中的任何位置；很容易出现误报)，并且不检查 SV1 是 gzip 测试的传统方式(因为 IE6SP2+ 版本不会受到该错误的影响)，因此它会破坏所有 IE 的压缩，这是不必要的。

它也不会设置Vary: User-Agent，因此代理将缓存错误的版本。当不使用 Content-Encoding 时，它会为 IE 设置 Vary: Accept-Encoding，因此它会 break cacheing in IE .

Should we make a copy of the gzip middleware module and edit the few lines that deal with IE and Javascript (this feels like we would be violating DRY)?

你可以，也许可以将补丁提交给 Django。因为在我看来，他们目前的方法完全被打破了。

Using Apache for gzip is also an option.

是的，如果您有 Apache 上游，那么一定要使用它(例如使用 mod_deflate)。如果您也可以使用它来提供脚本等静态文件，那么它是最有效的。 (尝试将 JS 保留在静态脚本中，而不是即时生成/模板化。)

再次强调，不要使用mod_deflate页面上提到的浏览器嗅探规则。他们脆弱而丑陋，并试图围绕过去十年中没有影响到任何人的 Netscape 问题进行编码。