I have two identical 64 bit Windows 2008 R2 Servers running IIS 7.5 (Production and QA).
Both have Dynamic Compression installed, enabled and configured in the same way.
Issue:
My Production server does NOT do dynamic gzip compression of ANYTHING, while the QA server DOES gzip compress what I expect it to.
The Good News is that the Failed Request Tracing Log shows a reason:
Reason Code: 12 NO_MATCHING_CONTENT_TYPE
The Bad News is that the compression settings in the applicationHost.config file for both servers are identical. I have never edited them by hand, I have WinMerge compared them (including whitespace) and I'm not configuring anything related to this in the web.config.
Here are the two compression related sections from the PROD machine (again, they are identical on the QA machine):
<section name="httpCompression" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">
<scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
<staticTypes>
<add mimeType="text/*" enabled="true" />
<add mimeType="message/*" enabled="true" />
<add mimeType="application/x-javascript" enabled="true" />
<add mimeType="application/atom+xml" enabled="true" />
<add mimeType="application/xaml+xml" enabled="true" />
<add mimeType="*/*" enabled="false" />
</staticTypes>
<dynamicTypes>
<add mimeType="text/*" enabled="true" />
<add mimeType="message/*" enabled="true" />
<add mimeType="application/x-javascript" enabled="true" />
<add mimeType="*/*" enabled="false" />
</dynamicTypes>
</httpCompression>
To me, it seems like with the configuration above, I should NOT get NO_MATCHING_CONTENT_TYPE. An ASPX files returns a content type of text/html and the configuration clearly shows that mimeType text/* is enabled.
Given the error message, I would think that many of the things I've checked in the following section shouldn't even apply (permissions / compression disable and enable cpu settings, etc...) but I wanted to look at everything as the possible cause.
More Info:
Keeping it simple, I'm only focusing on ASPX pages now (I'm trying to get "out of the box" compression to work, not something special like JSON...)
I believe that when I spun up these servers 6 months ago and configured compression, I verified that it worked from both of them. I haven't changed any config settings since then, so take this info for what it is worth.
I've gone through the following and they have not solved my problem:
www.iis.net/learn/troubleshoot/performance-issues/troubleshooting-iis-compression-issues-in-iis6-iis7x
stackoverflow.com/a/7634875/1131855
I have compared the servers' "Configuration Editor" settings for system.webServer/HttpCompression and both are IDENTICAL.
The dynamicCompressionDisableCpuUsage and dynamicCompressionEnableCpuUsage settings are their defaults at 90 and 50. While sometimes the web server CPU might hit 90%, I've monitored it often and it is almost always well below 50%.
I've checked the permissions of the user I have the ApplicationPool setup to use, and that user has FullControl permissions to the folder where the compression is done.
Here are the Request and Response Headers to the same page on each server:
PRODUCTION (compression not working)
GET /Default.aspx HTTP/1.1
Host: www.sitenameremoved.com
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36
Referer: https://www.sitenameremoved.com/auth/authLogon.aspx
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 274135
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Date: Thu, 19 Mar 2015 12:07:02 GMT
Strict-Transport-Security: max-age=7776000
QA (compression working)
GET /Default.aspx HTTP/1.1
Host: qa.sitenameremoved.com
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36
Referer: https://qa.sitenameremoved.com/auth/authLogon.aspx
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Date: Thu, 19 Mar 2015 12:08:16 GMT
Content-Length: 64963
Strict-Transport-Security: max-age=7776000
I've searched to the end of the internet. What am I missing?
Additional Possible Interesting Information (added later)
To see if I could reproduce the issue on my QA box, I used the Configuration Editor to REMOVE the text/* mime type from the "dynamicTypes" entry under system.webServer/httpCompression.
I enabled Failed Request Tracing, restarted the IIS, hit the logon page and saw in Fiddler that it wasn't gzipped. I looked at the xml file generated by the Failed Request Trace and as expected, Dynamic Compression failed due with the reason of 12 NO_MATCHING_CONTENT_TYPE.
I then added the text/* mime type back, restarted IIS, and of course compression is working again.
I recycle the AppPool once a week on the Prod Server, but tonight I'll recycle IIS and see if it reads the config settings and starts working...
Thanks, Brent
