如果我们不支持IE6,为IE浏览Jzip文件是否有意义？

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.Accept-Encoding根据标准HTTP/1.1,将压缩的HTML/JS/CSS发送到请求它的所有浏览器(带).

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

噢亲爱的.即使是UA嗅探的惨淡标准,这也是一个非常糟糕的测试.没有检查它实际上是MSIE在字符串中的正确位置(与所有尾随位中的任何位置相对;容易得到误报),并且它不检查SV1哪个是传统的gzip测试(因为IE6SP2 +版本不能受到bug的影响),所以它打破了所有 IE的压缩,这是不必要的.

它也没有设置Vary: User-Agent,因此代理将缓存错误的版本.并且它Vary: Accept-Encoding在不使用时为IE 设置Content-Encoding,因此它将在IE中打破缓存.

我们是否应该制作gzip中间件模块的副本并编辑处理IE和Javascript的几行(这感觉就像我们会违反DRY)？

你可以,也许可以将补丁提交给Django.因为他们目前的方法是IMO完全被打破.

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

是的,如果你有Apache上游肯定使用它(例如.mod_deflate).如果您可以使用它来提供脚本等静态文件,那么效率最高.(尝试将JS保存在静态脚本中,而不是在运行中生成/模板化.)

同样,请勿使用mod_deflate页面上提到的浏览器嗅探规则.他们是脆弱和丑陋的,并且正试图编写一个在过去十年中影响到没有人的网景问题.