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).

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!!)
–
alexanderOct 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 OehlertOct 20 '11 at 0:28

3

@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 HaglundSep 17 '12 at 20:34

3 Answers
3

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.

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 KumbharMar 22 '10 at 23:40

@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 OehlertDec 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
–
avs099Dec 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.
–
mcw0933Oct 13 '14 at 18:04

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.