Windows 8 apparently removes content-encoding header from compressed HTTP responses

Question

I'm not completely sure whether this belongs on SO, but I don't know where else to ask.

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.

• 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):

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:

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.

Now my questions:

• Can anybody confirm that Windows 8 modifies HTTP responses and that it works the way I described?
• Is there a way to monitor or even disable this behavior?

Thanks in advance for your answers.

Regards, Andre

---

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.

This confirms my assumption that Windows 8 is intervening.

Mook

Have you checked at the network level on the client with Wireshark? Maybe it's your ISP. – Banian

Do you have a proxy server or fancy router on your network? It may decompress the data to inspect it, and send the decompressed response to you. – Graptolite

I did the test with Windows 8 and Windows 7 machines on exactly the same network, ie. the same internet provider and the same network infrastructure. I'll try to dig into the network traffic with wireshark and see what I can find. – Mook

I updated my question with the Wireshark protocol: the response arrives compressed and with the content-encoding header but still appears as non-compressed in the browser. I'm really curious what Windows is doing here. – Mook

Answer 1

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.

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.

Mook

I have the same problem. But the browser still doesn't appear compressed after I turn off my antivirus software – Lark

Same exact thing is happening to me as well, and I'd suspect Microsoft's Windows Defender or one of Microsofts highly suspect "security updates" long before I'd suspect my AV software. And yes, I disabled the AV and the problem still exists. – Straightaway