Home/ Questions/Q 8873245
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T18:25:00+00:00

I’m not completely sure whether this belongs on SO, but I don’t know where

  • 0

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):
response headers on client machine

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:

server side compression

Also, the server seems to send the proper headers:

compression 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.

wireshark

This confirms my assumption that Windows 8 is intervening.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0