Windows 8显然从压缩的HTTP响应中删除了内容编码头

And*_*ker 12 http http-compression http-headers windows-8

我不完全确定这是否属于SO,但我不知道还有什么要问的.

当我检查我的网络应用程序的加载速度时,我注意到显然没有HTTP响应(无论什么类型 - html,css,js)是压缩gzip/deflate.也就是说,任何请求中都不存在像"Content-Encoding:gzip"这样的响应标头,并且浏览器报告资源未被压缩.

  • 在多种浏览器中测试和确认(IE10,FF 17,Chrome 23,Opera 12.10,Safari 5.x)
  • 在运行Windows 8 Pro的两台计算机上测试并确认
  • 使用Fiddler进行双重检查 - 响应未压缩且不包含内容编码标头
  • 这不只是发生于我的网络应用程序,没有我测试的其他网站出现发送压缩响应(根据浏览器)
  • 在Windows 7上,响应压缩并带有所有标头
  • HTTPS响应压缩

以下是响应标头的示例(请注意缺少内容编码标头): 客户端计算机上的响应头

我还检查了服务器端.服务器正在运行Windows Server 2008 R2/IIS 7.5.我使用Failed Request Tracing查找服务器发送的内容.资源似乎是压缩的:

服务器端压缩

此外,服务器似乎发送正确的标头:

压缩标头

我的结论是:必须是Windows 8谁在这里进行干预.显然它修改了HTTP响应.我想Windows 8正在接收压缩响应,对其进行解压缩,删除内容编码头并将修改后的响应传递到管道下方.

现在我的问题:

  • 任何人都可以确认Windows 8修改HTTP响应并且它按照我描述的方式工作吗?
  • 有没有办法监控甚至禁用此行为?

提前感谢您的回答.

问候,安德烈


更新:我使用Wireshark查看到达客户端的内容.正如我所料,资源被压缩,内容编码头仍然存在.下图显示了wireshark协议,右下角显示了Chrome收到的响应.

Wireshark的

这证实了我的假设,即Windows 8正在介入.

And*_*ker 9

事实证明,罪魁祸首是我的防病毒软件Avast,更具体地说是集成的实时网络屏蔽.将其关闭会导致响应再次在浏览器中显示为压缩.

仍然有趣的是,Avast也在Windows 7机器上运行,即使在那些机器上我在测试期间压缩的地方也是如此.