Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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.

like image 935
Andre Loker Avatar asked Nov 22 '12 16:11

Andre Loker


People also ask

Are HTTP headers compressed?

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.

How do I add a accept-encoding header?

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.

What is HTTP content encoding?

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.

What does accept-encoding gzip deflate mean?

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.


1 Answers

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.

like image 106
Andre Loker Avatar answered Jan 01 '23 08:01

Andre Loker