IIS as a reverse proxy - compression of rewritten response from backend server

Question 1

I have figured it out myself.

What needs to be done to get it working:

Accept-Encoding header must be removed before routing the request to the backend server, so that the response can be rewritten using outbound rules
the header must be restored by an additional accompanying outbound rule, so that it is present when the compression module kicks in before the response is sent to the client

I have decided to do it like this:

add a new server variable to the rewrite rule to hold he original header sent by the client:
```
<set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="{HTTP_ACCEPT_ENCODING}" />
```
(I put it before the line which clears the HTTP_ACCEPT_ENCODING variable)

add a new outbound rule:

<rule name="RestoreAcceptEncoding" preCondition="NeedsRestoringAcceptEncoding">
  <match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
  <action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
</rule>

and an accompanying precondition:

<preCondition name="NeedsRestoringAcceptEncoding">
  <add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />
</preCondition>

Works like a charm so far.

Question 2

To address the original poster's issue while still preserving gzip compressed responses, one simply needs to do the following:

update the registry on your public facing web server as such:

a. For 64bit web sites, run the following in a command console with admin rights: reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0

b. For 32bit web sites, run the following in a command console with admin rights: reg add HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432node\Microsoft\Inetstp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0
reset IIS
disable static compression

a. to accomplish this, I inserted the following my web config: <urlCompression doStaticCompression="false" doDynamicCompression="true" dynamicCompressionBeforeCache="false" />
in the server node in IIS manager, double click on the Modules icon, then on the right, click "view ordered List" and verify that your static/dynamic compression modules are towards the top and the URL rewrite module is toward the bottom

Please Note

I see a lot of resolutions to this issue floating around the net where the HTTP_CONTENT_TYPE request header is being cleared out as part of the URL rewrite rule (including answers on this page). One should be aware that while this does resolve the original issue of the 500.52 error, gzip compression on the response is REMOVED. This may be the desired outcome, but if gzip compression required, the above solution will do the trick

Question 3

PS: The below solution only works if you have control over your app server.

It's basically letting the web server do the compression, and let the app server do the heavy duty of what the app is supposed to do (without compression).

If you disable the compression on the app server, the response you get from app server is uncompressed. On the web server, you should enable the compression, so web server will honor the HTTP header "Accept-Encoding: gzip,deflate" while responding to client (browser).

This configuration will offload the CPU on the app server but will increase the network traffic between your web server and app server. If you are on the internal network, it doesn't have much performance impact.

Question 4

Just adding a "serverVariables" tag in the rewrite rule did the trick for me:

<rewrite>
        <rules>
            <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                <match url="(.*)" />
                <action type="Rewrite" url="http://otherurl{R:1}" />

                <serverVariables>
                    <set name="HTTP_ACCEPT_ENCODING" value="" />
                </serverVariables>
            </rule>

       </rules>
</rewrite>