IIS Outbound Rules with gzip compression

Saotn.org used URL Rewrite Outbound Rules in IIS to offload content from a different server or host name. Doing so, IIS uses URL Rewrite and acts as a reverse proxy. Add gzip compression to the mix, and this will improve website performance. But just recently I noticed Outbound Rules conflicted with gzip compressed content. The following HTTP 500.52 URL Rewrite Module Error was thrown:

Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded ("gzip").

HTTP Error 500.52 - URL Rewrite Module Error.

Fix for Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded ("gzip").

Searching Google (search query) there is a number of reports and possible solutions.

Some of the solutions included the steps:

1. Set the LogRewrittenUrlEnabled registry key:
   reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0
2. Make sure that dynamicCompressionBeforeCache property is set to false for the /system.webServer/urlCompression configuration element.
3. Re-order the IIS modules to have URL Rewrite run before Dynamic Compression module (DynamicCompressionModule). In the IIS Manager user interface in the modules's ordered view the Dynamic Compression module should be above the URL Rewrite module.

But I didn't want to fiddle with Windows Server's registry, which I'm sure you can imagine. The Stack Overflow post IIS as a reverse proxy - compression of rewritten response from backend server was what really set me on the right track.

Want to learn how to install IIS URL Rewrite Module?

This is how I fixed IIS Outbound Rules with gzip compressed content:

Through the IIS Manager GUI, add two Allowed Server Variables:

1. HTTP_ACCEPT_ENCODING
2. HTTP_X_ORIGINAL_ACCEPT_ENCODING

Ask your administrator if you don't have access. We use these server variables to store the contents of HTTP_ACCEPT_ENCODING into HTTP_X_ORIGINAL_ACCEPT_ENCODING, right before we remove the HTTP_ACCEPT_ENCODING header. Removing this header is necessary.

Then, in your web.config file set up the inbound and outbound rewrite rules:

1. Add an outboundRule to restore the HTTP_ACCEPT_ENCODING header with the contents of HTTP_X_ORIGINAL_ACCEPT_ENCODING.
2. Add a preCondition required by the outboundRule.

Putting this all together, I came up with the following web.config URL Rewrite rules:

<rewrite>
  <rules>
    <rule name="wordpress" patternSyntax="Wildcard">
      <match url="*"/>
    <conditions>
      <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
      <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
    </conditions>
    <serverVariables>
      <set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="{HTTP_ACCEPT_ENCODING}" />
      <set name="HTTP_ACCEPT_ENCODING" value=""/>
    </serverVariables>
      <action type="Rewrite" url="index.php"/>
     </rule>
  </rules>

  <outboundRules rewriteBeforeCache="true">
    <rule name="RestoreAcceptEncoding" preCondition="NeedsRestoringAcceptEncoding">
      <match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
      <action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
    </rule>
    <preConditions>
      <preCondition name="NeedsRestoringAcceptEncoding">
    <add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />
      </preCondition>
    </preConditions>
  </outboundRules>
</rewrite>

Disclamer: This works for my set up, it may not work for yours. I'd love to hear your response!