When configuring compression in IIS7, many developers encounter the specific issue where HTTP/1.0 requests fail to receive compressed responses despite proper web.config settings. The trace logs typically show:
DYNAMIC_COMPRESSION_START
DYNAMIC_COMPRESSION_NOT_SUCESS
Reason: 3
Reason: NO_COMPRESSION_10
DYNAMIC_COMPRESSION_END
For HTTP/1.0 compression to work, three critical elements must be properly configured:
<system.webServer>
<urlCompression
doDynamicCompression="true"
dynamicCompressionBeforeCache="true" />
<httpCompression
noCompressionForHttp10="False"
noCompressionForProxies="False" />
</system.webServer>
While IIS allows compression settings in multiple configuration files (Machine.config, ApplicationHost.config, etc.), website-specific settings in web.config should work when:
- The application pool is running in Integrated mode
- The configuration section isn't locked at server level
- HTTP compression feature is installed
To confirm your settings are being applied:
- Check applicationHost.config for locked sections:
%windir%\system32\inetsrv\appcmd unlock config -section:system.webServer/httpCompression
- Verify feature installation:
Get-WindowsFeature Web-Dyn-Compression
Here's a verified working configuration for HTTP/1.0 compression:
<configuration>
<system.webServer>
<urlCompression doDynamicCompression="true" />
<httpCompression
directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files"
noCompressionForHttp10="false"
noCompressionForProxies="false"
sendCacheHeaders="true">
<dynamicTypes>
<add mimeType="text/*" enabled="true" />
<add mimeType="application/javascript" enabled="true" />
<!-- Additional MIME types -->
</dynamicTypes>
</httpCompression>
</system.webServer>
</configuration>
If the above doesn't work, you may need to modify the server-wide defaults in applicationHost.config. Look for these sections:
<section name="httpCompression" overrideModeDefault="Allow" />
<section name="urlCompression" overrideModeDefault="Allow" />
Ensure they're not set to "Deny" which would prevent web.config overrides.
Enabling compression for HTTP/1.0 may impact:
- CPU usage - monitor performance counters
- Cache efficiency - test with dynamicCompressionBeforeCache
- Client compatibility - test with legacy systems
I recently encountered an issue where IIS7 wasn't applying gzip compression to HTTP 1.0 requests, despite having the correct settings in my web.config file. The server was properly compressing HTTP 1.1 responses, but tracing showed the following error:
DYNAMIC_COMPRESSION_START
DYNAMIC_COMPRESSION_NOT_SUCESS
Reason: 3
Reason: NO_COMPRESSION_10
DYNAMIC_COMPRESSION_END
According to Microsoft's documentation, compression settings can be configured at multiple levels:
- Machine.config
- ApplicationHost.config
- Root application Web.config
- Application Web.config
- Directory Web.config
This means you can configure compression settings at the application level through web.config, but there are some important considerations.
After some experimentation, here's the configuration that finally worked for me:
<system.webServer>
<urlCompression
doDynamicCompression="true"
dynamicCompressionBeforeCache="true" />
<httpCompression
staticCompressionIgnoreHitFrequency="true"
dynamicCompressionIgnoreHitFrequency="true"
noCompressionForHttp10="false"
noCompressionForProxies="false">
<scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
<dynamicTypes>
<add mimeType="text/*" enabled="true" />
<add mimeType="application/json" enabled="true" />
<add mimeType="application/javascript" enabled="true" />
<add mimeType="*/*" enabled="false" />
</dynamicTypes>
</httpCompression>
</system.webServer>
Several important settings made the difference:
noCompressionForHttp10="false"
- This is the main setting to enable compression for HTTP 1.0- Explicitly listing the compression schemes (gzip in this case)
- Defining specific dynamic types that should be compressed
- Setting compression frequency parameters to ignore hit frequency
To verify your configuration is working:
- Use a tool like Fiddler or Postman to send HTTP 1.0 requests
- Check the response headers for "Content-Encoding: gzip"
- Compare response sizes between compressed and uncompressed versions
- Examine the IIS Failed Request Tracing logs
Some issues I encountered during implementation:
- Conflicting settings in parent configuration files
- Missing scheme definitions in httpCompression
- Incorrect mime type definitions
- Cache-related settings interfering with compression
Remember that some older clients might have issues with compressed content, so test thoroughly with your target audience.