I'm trying to configure my IIS7 compression settings in my web.config file. I'm trying to enable HTTP 1.0 requests to be gzip.

MSDN has all the info about it here.

Is it possible to have this config info in my own website's web.config file? Or do i need to set it at an application level? Currently, I have that code in my web.config...

        dynamicCompressionBeforeCache="true" />
        sendCacheHeaders="true" />

    ... other stuff snipped ...


It's not working :( HTTP 1.1 requests are getting compressed, just not 1.0.

That MSDN page above says that it can be used in :-

  • Machine.config
  • ApplicationHost.config
  • Root application Web.config
  • Application Web.config
  • Directory Web.config

So, can we set these settings on a per-website-basis, programatically in a web.config file? (this is an Application Web.config file...) What have i done wrong?

cheers :)

EDIT: I was asked how i know HTTP1.0 is not getting compressed. I'm using the Failed Request Tracing Rules, which reports back:-

    Reason: 3
    Reason: NO_COMPRESSION_10

Pay close attention to the fact that the IIS 7.x web.config setting of


Is not honored at the web.config level. It must be set in C:\Windows\System32\inetsrv\config\ApplicationHost.config like so:

<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files" noCompressionForProxies="False">

Be sure and perform an IIS reset after changing the setting.

A request is determined to be from a proxy by IIS if the client's web request has the HTTP "Via" header like so:

Via: 1.1 foo
  • You can also use appcmd to set application level settings (which is probably much easier). – Pure.Krome Oct 13 '11 at 2:44

After a fair bit of research, it is 'locked' by default at the application level. As such, it needs to be 'unlocked'. this can be achieved via the command line or via the (extra download) iis7 admin tools.

eg. appcmd set config -section:urlCompression /doDynamicCompression:true



How are you testing that HTTP1.0 requests are not being compressed? Could it be that the client that you are using is not telling the server that it can accept a compressed response?

If you can see the headers sent by the client (presented by the test client itself, using Firebug or similar if you are testing in Firefox or IEHTTPHeaders if you are testing in IE, or by sniffing the traffic using an external tool), you should see something like

Accept-Encoding: compress, gzip, deflate

in there somewhere. If the client does not inform the server that it can accept a compressed response then the server will not send one no matter what other settings you have server side.

Another issue could be if you are testing through a proxy server that identified itself as such. In this case the noCompressionForProxies setting might be taking precedence and blocking the possibility of a compressed response.

One thing to note is that some clients and proxys that send HTTP1.0 requests (usually older software) will not correctly handle a compressed response if they get one, so if you do enable compression for responses to HTTP1.0 requests make sure that you test your site/application in all the client/proxy software you expect visitors/users to use. This is less of an issue if you can guarantee your target audience will be using certain software (if for instance the app is for an internal corporate network only) but otherwise there are a lot of combinations to test which is why most servers disable compression for 1.0 requests completely.

  • I'm testing that HTTP1.0 requests are not getting compressed by using the Failed Request Tracing Rules, which reports back:- DYNAMIC_COMPRESSION_START DYNAMIC_COMPRESSION_NOT_SUCESS Reason: 3 Reason: NO_COMPRESSION_10 DYNAMIC_COMPRESSION_END – Pure.Krome Jun 11 '09 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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