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.
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:
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.
This results in a unique Gzip data format, also named Gzip, which wraps DEFLATE compressed data with a checksum and header. Due to early problems with DEFLATE, some users prefer to only use Gzip. Typically, HTTP headers are not compressed, as HTTP content-encoding based compression applies to the response body only.
To check this Accept-Encoding in action go to Inspect Element -> Network check the request header for Accept-Encoding like below, Accept-Encoding is highlighted you can see.
Content encoding is mainly used to compress the message data without losing information about the origin media type. Note that the original media/content type is specified in the Content-Type header, and that the Content-Encoding applies to the representation, or "coded form", of the data.
It means the client can accept a response which has been compressed using the DEFLATE algorithm. https://en.wikipedia.org/wiki/Deflate This algorithm is also used in gzip compression format.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With