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

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

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

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

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

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

为此我强烈推荐删除所有现有的用户代理嗅探 gzip 黑客攻击。将压缩的 HTML/JS/CSS 发送到所有请求它的浏览器（使用Accept-Encoding），根据标准 HTTP/1.1。

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

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

也没有设置Vary: User-Agent，因此代理将缓存错误的版本。它设置Vary: Accept-Encoding不使用 IE 时Content-Encoding，所以它会打破IE缓存 https://web.archive.org/web/20160224221410/http://blogs.msdn.com:80/b/ieinternals/archive/2009/06/17/vary-header-prevents-caching-in-ie.aspx.

我们是否应该复制 gzip 中间件模块并编辑处理 IE 和 Javascript 的几行（这感觉就像我们违反了 DRY）？

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

使用 Apache 进行 gzip 也是一种选择。

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

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