视窗8显然是从压缩的HTTP响应中删除内容-encoding头(Windows 8 apparent

我不能完全肯定这是否属于SO，但我不知道还有什么地方可以问。

当我检查我的web应用程序的加载速度，我注意到显然没有HTTP响应（不管是什么类型 - HTML，CSS，JS）是的gzip /紧缩压缩。 即，如“内容编码：gzip”没有响应标头是存在于任何请求和浏览器报告的资源不被压缩。

• 测试，并在多个浏览器确认（IE10，FF 17，铬23，歌剧12.10，Safari浏览器5.x的）
• 经过测试，确认在运行Windows 8 Pro的两台机器
• 双重检查使用Fiddler - 响应不被压缩，不包含内容-encoding头
• 这不只是发生于我的网络应用程序，我测试没有其他的网站似乎发送压缩响应（根据浏览器）
• 在Windows 7的响应到达的压缩，并与所有的头
• HTTPS 响应压缩

这里的响应报头（注意缺乏内容编码报头）的一个例子：

我还检查了服务器端。 服务器正在运行Windows Server 2008 R2 / IIS 7.5。 我曾经失败请求跟踪来找出服务器发送。 资源似乎被压缩：

此外，服务器似乎发送适当的标题：

我的结论是：它必须是Windows 8是谁在这里介入。 显然，它会修改HTTP响应。 我想，视窗8接收所述压缩的响应，解压缩，将删除内容编码标头和进一步经过修改的响应向下管道。

现在我的问题：

• 任何人都可以证实，Windows 8的修改HTTP响应，它的工作原理我所描述的方法是什么？
• 有没有一种方法来监控甚至禁用此行为？

在此先感谢您的回答。

问候，安德烈

---

更新：我使用Wireshark的，看在客户端什么到达。 正如我所期望的资源被压缩，内容编码头仍然存在。 下面的图像显示Wireshark的协议和在右下由铬接收到的响应。

这证实了我的假设，即Windows 8中的介入。

Answer 1:

原来，罪魁祸首是我的杀毒软件Avast的，更具体的集成实时网络屏蔽。 关闭它会导致响应在浏览器中再次出现压缩。

剩下有趣的是，Avast的是在Windows 7计算机上运行的很好，即使在这些机器的响应，其中压缩在我的测试适用。

文章来源: Windows 8 apparently removes content-encoding header from compressed HTTP responses