Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So, I'm a bit of an IIS7 n00b but I've used most of the old IIS systems going back to 3. I'm trying to turn on dynamic compression and it's working, mostly. It doesn't work for my ADO.Net Data Service (Astoria) requests, batched or not.

I found the failed request (FREB) tracing which was really helpful. And what I see on unbatched requests is Reason Code 12, NO_MATCHING_CONTENT_TYPE. OK, so I don't have the matching MIME type specified, that's easy.

Except this is what I have in my web.config (which I think is correct, but maybe not).

<httpCompression dynamicCompressionDisableCpuUsage="100"
                 dynamicCompressionEnableCpuUsage="100"
                 noCompressionForHttp10="false"
                 noCompressionForProxies="false"
                 noCompressionForRange="false"
                 sendCacheHeaders="true"
                 staticCompressionDisableCpuUsage="100"
                 staticCompressionEnableCpuUsage="100">
    <dynamicTypes>
        <clear/>
        <add mimeType="*/*"
             enabled="true" />
    </dynamicTypes>
    <staticTypes>
        <clear/>
        <add mimeType="*/*"
             enabled="true" />
    </staticTypes>
</httpCompression>
<urlCompression doDynamicCompression="true"
                doStaticCompression="true"
                dynamicCompressionBeforeCache="false" />

Now I think that this means it should compress any request that includes the Accept:Gzip header. I'd love to know what others might think here.

My fiddler trace:

GET /SecurityDataService.svc/GetCurrentAccount HTTP/1.1
Accept-Charset: UTF-8
Accept-Language: en-us
dataserviceversion: 1.0;Silverlight
Accept: application/atom+xml,application/xml
maxdataserviceversion: 1.0;Silverlight
Referer: http://sdev03/apptestpage.aspx
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.21022; .NET CLR 3.5.30729; InfoPath.2; .NET CLR 3.0.30729; OfficeLiveConnector.1.4; OfficeLivePatch.1.3)
Host: sdev03
Connection: Keep-Alive
Cookie: .ASPXAUTH=<snip>


HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: application/atom+xml;charset=utf-8
Server: Microsoft-IIS/7.0
DataServiceVersion: 1.0;
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 22 Mar 2010 22:29:06 GMT
Content-Length: 2726

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
*** <snip> removed ***
share|improve this question
    
DO USE NOTEPAD to edit applicationHost.config. I've wasted several hours before understood that my changes made in notepad++ (as well as in Visual Studio 2010 editor!!) aren't applied by IIS. Alternative way to add additional mimeType into dynamicTypes/staticTypes collection is to use appcmd. "C:\Windows\System32\Inetsrv\Appcmd.exe" set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/javascript',enabled='True']" /commit:apphost And again: after these changes made - you'll see them only in notepad. Notepad++ (as well as Visual Studio 2010 editor!!) –  alexander Oct 3 '11 at 12:01
    
Alexander, I'm not 100% certain I understand what you're saying here but I can say for certain that modifying IIS configuration with any text editor works just fine. You might have difficulty with an editor that adds a BOM marker, but other than that it should be fine. In my case, it wasn't that I couldn't use notepad to edit it, just that I was editing the wrong file. Not all configuration changes can be made in the web.config which is in the application web root. Some must be made against appHost in the System folder. –  Peter Oehlert Oct 20 '11 at 0:28
2  
@alexander: True, using 32-bit applications like notepad++ or visual studio on a 64-bit windows will get WOW64 to trigger file redirection for System32 folder. Editing will create a clone in C:\WINDOWS\SysWOW64 only visible to 32-bit programs and it will never be used by IIS that is a 64-bit program –  Fredrik Haglund Sep 17 '12 at 20:34

3 Answers 3

From a fresh install, my applicationHost.config (in %windir%\system32\inetsrv\config) had the following setting:

<section name="httpCompression" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />

... as well as a default set of MIME types to compress that, unfortunately, doesn't include JSON and other data types that would be good compression candidates.

Switching that to:

<section name="httpCompression" overrideModeDefault="Allow" />

enables configuration of the httpCompression tag under the system.webServer tag in my web.config.

I confirmed this by setting the httpCompression section of the applicationHost.config to:

<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">
    <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
    <dynamicTypes>
        <add mimeType="*/*" enabled="false" />
    </dynamicTypes>
    <staticTypes>
        <add mimeType="*/*" enabled="false" />
    </staticTypes>
</httpCompression>

... and now I can set all the MIME types I actually want to compress in the web.config.

share|improve this answer
    
The failed request tracing was very helpful for me in troubleshooting this: iis.net/learn/troubleshoot/using-failed-request-tracing/… –  mcw0933 Oct 13 at 18:14

Peter, thanks for the hint -- we also found that setting

<add mimeType="application/atom+xml; charset=utf-8" enabled="true" />

in the <httpCompression> section of applicationHost.config fixed this.

We also had to specify the encoding due to a bug in compression code:

There is a bug in the compression code that it does not parse the charset in the response header correctly, so you will have to configure "application/xml; charset=utf-8" in the dynamic compression settings to have it work.

Here's the relevant section in full

<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">
    <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" staticCompressionLevel="9" dynamicCompressionLevel="4" />
    <scheme name="deflate" dll="%Windir%\system32\inetsrv\gzip.dll" staticCompressionLevel="9" dynamicCompressionLevel="4" />
    <dynamicTypes>
        <add mimeType="text/*" enabled="true" />
        <add mimeType="message/*" enabled="true" />
        <add mimeType="application/x-javascript" enabled="true" />
        <add mimeType="application/atom+xml; charset=utf-8" enabled="true" />
        <add mimeType="*/*" enabled="false" />
    </dynamicTypes>
    <staticTypes>
        <add mimeType="text/*" enabled="true" />
        <add mimeType="message/*" enabled="true" />
        <add mimeType="application/javascript" enabled="true" />
        <add mimeType="*/*" enabled="false" />
    </staticTypes>
</httpCompression>
share|improve this answer
up vote 4 down vote accepted

OK, turns out you can't configure this in the web.config, only the appHost.config. I supposed the docs did say appHost.config but I had assumed it was a specification of a general concept, not the only allowable configuration location.

share|improve this answer
    
Correct. system.webServer configuration does not allows httpCompression at the Web site level. You can configure the same at the root i.e. in the applicationhost.config. –  Vivek Kumbhar Mar 22 '10 at 23:40
    
hmm.. docs DO say it can be applied at web.config level - scroll to the bottom: msdn.microsoft.com/en-us/library/ms690689(v=vs.90).aspx and look at "Configuration locations" table.. Is it a problem in the documentation? –  avs099 Dec 12 '13 at 18:50
    
@avs099 I don't know. When I posted this 3 years ago, I'm sure that I started with web.config and I posted b/c it wasn't working. Maybe the functionality changed in a patch or the docs are wrong. Would be good to test to find out. –  Peter Oehlert Dec 13 '13 at 17:05
    
oh - may be i was not clear - the way I read documentation, it says httpCompression CAN be used in web.config - but i was not able to get it working so I ended up modifying applicationHost.config file as well. To me that looks like documentation is misleading. I will link my answer at SO here: stackoverflow.com/a/20552186/1246870 –  avs099 Dec 13 '13 at 19:05
    
See my answer - by default, a clean IIS install turns off web.config overrides of compression settings, which is why you have to modify the applicationHost.config. Instead of changing the compression settings there though, you can just allow overrides instead, and you're back in business. –  mcw0933 Oct 13 at 18:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.