IIS application missing Content-Encoding - gzip in Response Header

Question

In Firebug the request header has the following entry:
Accept-Encoding: gzip, deflate

But there's no:
Content-Encoding: gzip
In the Response Header.

Regardless of anything I've tried, following a number of answers on SO and other sites, nothing seems to work! Neither static nor dynamic files are being compressed, or at least if they are there's no content encoding - gzip value coming back in the response header.

Here's an example of my web.config settings:

<urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="true" />
<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files" minFileSizeForComp="150" staticCompressionIgnoreHitFrequency="true">
  <remove name="gzip" />
  <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" staticCompressionLevel="8" dynamicCompressionLevel="8" />
</httpCompression>

I've ignored the hit frequency
staticCompressionIgnoreHitFrequency="true"

I've confirmed that IIS is in fact compressing the files which I can see in:
C:\inetpub\temp\IIS Temporary Compressed Files

As specified here: set up gzip in IIS 8 windows 8
I've ensured that static and dynamic compression is enabled in Windows Features > Internet Information Services > WWW Services > Performance Features

I've also tried this guy's approach:
IIS 7.5 Compression creates compressed file but returns the non-compressed one

---

Edit 1:
IIS version is 10 but I have also tried this on IIS 8.5

---

Edit 2:
I've now also tried various configuration files found at this link: https://github.com/h5bp/server-configs-iis/ which provides what looks like some 'best practice' web.config files.
Not solved

---

Edit 3:
Based on @Nkosi's input I created a completely new Asp.net MVC application and configured it using all these options I've tried. Here's the raw header that I got from Fiddler:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/javascript; charset=UTF-8
Expires: Wed, 20 Jul 2016 18:22:47 GMT
Last-Modified: Wed, 20 Jul 2016 18:22:47 GMT
Server: Microsoft-HTTPAPI/2.0
Date: Wed, 20 Jul 2016 18:22:47 GMT

As you can see, no Content-Encoding: Gzip
Not solved

---

Edit 4:
I've tried this approach of adding code to the BeginRequest event in the Global.asax section: https://mcmap.net/q/282369/-how-to-enable-gzip-compression-in-iis-7-5
Not solved

---

Edit 5:
So I just tried enabling tracing based on this answer on SO: https://mcmap.net/q/282370/-how-do-i-enable-failed-request-tracing-in-iis-10-0-on-windows-10-development-pc
No failures, but I did notice right at the bottom of the trace file there's a section called GENERAL_RESPONSE_HEADERS and here's what it provides:

Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Server: Microsoft-IIS/10.0
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319
X-Powered-By: My Little Pony
X-UA-Compatible: IE=Edge,chrome=1

And that's for every static type file.
However I just found the following in the trace file:

8. STATIC_COMPRESSION_START  08:04:03.552 
9. STATIC_COMPRESSION_NOT_SUCCESS Reason="NOT_FREQUENTLY_HIT" 08:04:03.552 
10. STATIC_COMPRESSION_END  08:04:03.552 

Compression Not Success for the reason Not Frequently Hit... Odd because I definitely have the Ignore Hit Frequency option set to true!

So I just went into IIS Manager and on the server I set the Ignore Hit Frequency to true (i.e. applicationHost.config) and it changed the trace file output to the following:

8. STATIC_COMPRESSION_START  08:19:17.489 
9. STATIC_COMPRESSION_SUCCESS  08:19:17.489 
10. STATIC_COMPRESSION_END  08:19:17.489 

I went back and switched it off in the applicationHost.config and it went back to a Static Compression Not Success, so this definitely makes a difference. However, when I look at FireBug, it's still delivery the uncompressed file and no GZIP Content Encoding response header.

Another interesting bit I noticed in the Failed Request Trace is the final two entires GENERAL_FLUSH_RESPONSE_END and GENERAL_REQUEST_END both of which show my Bootstrap.css file as having sent 17903 bytes, roughly 18kb, matching the compressed version of the file I see in my IIS Temporary Compressed Files folder. So the file is physically being compressed and according to Failed Request traces it's sending down the right content... but then the browser picks up the full 117kb file instead?
Not solved

---

Bernhard

I am using IIS10 and my web.config has <urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="false" /> only. When I do test requests from a browser (Firefox, IE11, Edge, Google Chrome) to a simple MVC application. The requests all have Accept-Encoding: gzip, deflate and the responses return Content-Encoding:gzip – Hermineherminia

See this. Maybe you need to enable gzip feature on server. – Ean

@LucasSegers - The feature is definitely enabled. – Bernhard

I am having the same problem, where the Failed Request Trace is showing the file has been compressed ok. With the correct response header showing in GENERAL_FLUSH_RESPONSE_START and correct size in GENERAL_REQUEST_END, but the browser still picking up the full file. – Donelson

I'm experience the same issue. Was there ever an answer? – Dex

@Dex not one that solved my problem no. – Bernhard

@Bernhard For me the issue was the antivirus on my machine was stripping out the "Content-Encoding" response header. – Dex

@Bernhard As MakkyNZ mentioned, most common reason is antivirus. I faced this issue several times as well. Everything seems properly configured on server/response side in described scenario, so it looks like that something unzips compressed files. Even Fiddler cannot help here, while it seems that Wireshark helps (looks ilke it intercepts response on even lower level than antivirus). One quick and simple way to bypass antivirus is to check if content is gzipped when using https/SSL. – Egg

Answer 1

I have similar situation with IIS and gzip configuration

In Firebug the request header has the following entry: Accept-Encoding: gzip, deflate

But there's no: Content-Encoding: gzip In the Response Header.

In my case problem was with antivirus protection. Actually gzipping was applied but antivirus with enabled settings protect http connections (depends on concrete program), unzip response check it and after that rewrite response headers on the fly.

NOTE: A key attribute when some proxy/antivirus changed your response headers, it is when disappear Content-Length and Transfer-Encoding is added with value chunked.

Hale

Thanks. You saved my day. Eset nod was changing the response header and unzipping the response – Phyliciaphylis

It looks like anti virus' programs intercept the archive and extract it before passing it over to the browser so the browser will always receive it uncompressed whilst this is active. Try testing on a machine with just the windows defender or the anti virus turned off and see if you get the content-encoding then – Oxendine

Answer 2

I am using IIS10 and my web.config has

<system.webServer>
    <urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="false" />
    <!-- other config removed for brevity -->
</system.webServer>

When I do test requests from a browser (Firefox, IE11, Edge, Google Chrome) to a simple MVC application.

The requests all have Accept-Encoding: gzip, deflate and the responses return Content-Encoding:gzip.

I Even tested it with Fiddler. Composing the request manually

GET http://localhost/MyWebApplication HTTP/1.1
User-Agent: Fiddler
Host: localhost
Accept-Encoding: gzip, deflate

and get the same result

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/10.0
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 18 Jul 2016 15:26:06 GMT
Content-Length: 3826

...

Css, Js and all other text based files are being compressed.

You may need to re-check your configuration to make sure you have the compression properly configured in IIS and your web.config.

UPDATE:

I did notice that images were not being compressed

Request

GET http://localhost/MyWebApplication/Images/Logo_small.png HTTP/1.1
User-Agent: Fiddler
Host: localhost
Accept-Encoding: gzip, deflate

Response

HTTP/1.1 200 OK
Cache-Control: max-age=604800
Content-Type: image/png
Last-Modified: Fri, 27 Nov 2015 03:15:22 GMT
Accept-Ranges: bytes
ETag: "c9d1fdd9c128d11:0"
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Date: Mon, 18 Jul 2016 15:33:02 GMT
Content-Length: 2970

...

And after some google-fu found out that the images are usually already compressed so gzip was not applied.

FULL system.webServer from web.config

  <system.webServer>
    <urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="false" />
   <validation validateIntegratedModeConfiguration="false" />
    <httpErrors errorMode="Custom" existingResponse="Replace">
      <clear />
      <error statusCode="404" responseMode="ExecuteURL" path="/NotFound" />
    </httpErrors>
    <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <remove name="OPTIONSVerbHandler" />
      <remove name="TRACEVerbHandler" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
    <staticContent>
      <remove fileExtension=".woff" />
      <remove fileExtension=".woff2" />
      <mimeMap fileExtension=".woff" mimeType="application/font-woff" />
      <mimeMap fileExtension=".woff2" mimeType="application/font-woff2" />
      <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="7.00:00:00" />
    </staticContent>
  </system.webServer>

Hermineherminia

I've updated my question, see Edit 3. What code did you remove from your example, anything that could change my results? – Bernhard

@Jacques, the rest of the config is httpErrors, handler, staticContent. I kept it minimal. I'll include it in the an update. – Hermineherminia

okay I don't think that would impact this issue. I've added another update with another solution I've just tried, still no joy. – Bernhard

Answer 3

I have just had the same problem. The cause ended up being the dynamicCompressionBeforeCache="true" setting. Changing this attribute to "false" fixed the problem.

<urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="false" />

I run a few sites on a shared server provided by SmarterASP.Net. I raised a support ticket with them and along the way I determined dynamicCompressionBeforeCache="true" to be the culprit.

I pointed them to the Microsoft documentation covering this attribute, at https://learn.microsoft.com/en-us/iis/configuration/system.webserver/urlcompression, and asked them why a setting of "true" would be causing this issue.

SmarterASP.Net support referred to a section of the documentation stating...

If the dynamicCompressionBeforeCache attribute is true when the output cache response has been flushed, dynamic compression will not be performed before the response is put into the output cache.

...and they said...

"We do not save output cache in our server end. So the output cache responses always got flushed and caused the issue."

I can't say that I fully understand the mechanics here, or why SmarterASP.Net don't save the output cache. But a setting of dynamicCompressionBeforeCache="false" definitely solved the problem for me.

Soekarno

Answer 4

I know this is an old post but I stumbled onto it so im going to respond anyways. I was trying to host a unity game on an IIS server running on an EC2 instance. I did all the stuff above like enabling content compression but it still didn't have the "Content-Encoding" in the response. The reason it was broken was because I built the game in unity with gzip compression before putting it on the server, instead of building with no compression and letting the server handle it. The issue was something along the lines of compressing the files twice or maybe not compressing them since they were already compressed.

Dowry