Windows 8显然从压缩的HTTP响应中删除了内容编码头 [英] Windows 8 apparently removes content-encoding header from compressed HTTP responses
问题描述
我不完全确定这是否属于SO，但我不知道还能在哪里问。
I'm not completely sure whether this belongs on SO, but I don't know where else to ask.
当我检查加载速度时我的网络应用程序我注意到，显然没有HTTP响应（无论什么类型 - html，css，js）是gzip / deflate压缩。也就是说，任何请求中都没有Content-Encoding：gzip等响应标头，并且浏览器报告资源未被压缩。
While I was checking the loading speed of a web app of mine I noticed that apparently no HTTP response (no matter what type - html, css, js) is gzip/deflate compressed. That is, no response header like "Content-Encoding: gzip" is present in any request and the browser reports that the resource is not compressed.
- 在多台浏览器（IE10，FF 17，Chrome 23，Opera 12.10，Safari 5.x）中测试并确认
- 在运行Windows 8 Pro的两台计算机上测试并确认
- 使用Fiddler进行双重检查 - 响应未压缩且不包含内容编码标题
- 这不仅适用于我的网络应用，没有我测试过的其他网站似乎发送了压缩响应（根据浏览器）
- 在Windows 7上，响应压缩并且包含所有标题
- HTTPS响应 压缩
- tested and confirmed in multiple browsers (IE10, FF 17, Chrome 23, Opera 12.10, Safari 5.x)
- tested and confirmed on two machines running Windows 8 Pro
- double checked with Fiddler - the response is not compressed and does not contain a content-encoding header
- this doesn't only happen for my web apps, no other web site I tested appears to send compressed responses (according to the browser)
- on Windows 7 the responses arrive compressed and with all headers
- HTTPS responses are compressed
以下是响应标头的示例（请注意缺少内容编码标题）：
Here's an example of the response headers (note the lack of the content-encoding header):
我也查一下在服务器端。该服务器正在运行Windows Server 2008 R2 / IIS 7.5。我使用Failed Request Tracing查找服务器正在发送的内容。该资源似乎是压缩的：
I also checked the server side. The server is running Windows Server 2008 R2/IIS 7.5. I used Failed Request Tracing to find out what the server is sending. The resource appears to be compressed:
此外，服务器似乎发送了正确的标题：
Also, the server seems to send the proper headers:
我的结论：它必须是Windows 8谁在这里进行干预。显然它修改了HTTP响应。我想Windows 8正在接收压缩响应，对其进行解压缩，删除内容编码头并将修改后的响应传递到管道中。
My conclusion: it must be Windows 8 who is intervening here. Apparently it modifies HTTP responses. I suppose that Windows 8 is receiving the compressed response, decompresses it, removes the content-encoding header and passes the modified response further down the pipeline.
现在我的问题：
- 任何人都可以确认Windows 8修改了HTTP响应并且它按照我描述的方式工作吗？
- 有没有办法监控甚至禁用此行为？
提前感谢您的回答。
问候，
Andre
Regards, Andre
更新：
我使用Wireshark来看到什么到达客户端。正如我所料，资源被压缩，内容编码头仍然存在。下图显示了wireshark协议，右下角显示了Chrome收到的响应。
Update: I used Wireshark to see what arrives at the client. As I expected the resources are compressed and the content-encoding header is still present. The image below shows the wireshark protocol and in the bottom right the response as received by Chrome.
这证实了我的假设，即Windows 8正在介入。
This confirms my assumption that Windows 8 is intervening.
推荐答案
原来，罪魁祸首是我的防病毒软件Avast，更具体地说是集成的实时网络屏蔽。关闭它会导致响应再次在浏览器中显示为压缩。
It turned out that the culprit was my antivirus software, Avast, more specifically the integrated real-time network-shield. Turning it off causes responses to appear compressed in the browsers again.
有趣的是，Avast也在Windows 7计算机上运行，即使在那些计算机上响应在我的测试中适用的地方压缩。
What remains interesting is that Avast was running on the Windows 7 machines as well, even though on those machines responses where compressed where applicable during my tests.
这篇关于Windows 8显然从压缩的HTTP响应中删除了内容编码头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
