question

@IanNewson-4570

This is because the responses that are coming from the back-end server are using HTTP Compression, and URL rewrite cannot modify a response that is already compressed. This causes a processing error for the outbound rule resulting in the 500.52 status code.

There are two ways to work around this: either you turn off compression on the backend server that is delivering the HTTP responses (which may or may not be possible, depending on your configuration), or we attempt to indicate to the backend server the client does not accept compressed responses by removing the header when the request comes into the IIS reverse proxy and by placing it back when the response leaves the IIS server.

With regards to the removal and re-instatement of the HTTP header, you need to add two variables named HTTP_ACCEPT_ENCODING and HTTP_X_ORIGINAL_ACCEPT_ENCODING in URL Rewrite, once this is complete, you need to use these variables both in the inbound rules, to remove the Accept-Encoding header and in the Outbound Rules to place this header back again.
The final rule should be as follows:

 <rule name="ReverseProxyInboundRule1" stopProcessing="true">
      <match url="(.*)" />
      <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
      <serverVariables>
          <set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING"    value="{HTTP_ACCEPT_ENCODING}" />
          <set name="HTTP_ACCEPT_ENCODING" value="" />
      </serverVariables>
 </rule>

Then you need to modify the outbound rules, when you receive the responses from the backend server, you need to forward them back to the browser. To be able to correctly do this, you will need to restore the value of the HTTP_ACCEPT_ENCODING variable to what it was before you changed it to empty. Create a new Outbound Rule from the URL Rewrite Pane, by clicking the ‘Add Rule’ action link on the right hand side pane, and then selecting the ‘Blank Rule’ from the Outbound Rules section of the ‘Add Rule(s)’ Window.

 <outboundrules>
          <rule name="ReverseProxyOutboundRule1" precondition="ResponseIsHtml1">
                 <match filterbytags="None" pattern="href=(.*?)http://privateserver:8080/(.*?)\s">
    
                        <action type="Rewrite" value="href={R:1}http://www.mypublicserver.com/{R:2} ">
                         </action>
                  </match>
            </rule>
            <rule name="Restore-AcceptEncoding"  precondition="NeedsRestoringAcceptEncoding">
                  <match servervariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)"></match>
                   <action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}"> </action>
           </rule>
          <preconditions>
               <precondition name="ResponseIsHtml1">
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/(.+)"></add>
                </precondition>
                <precondition name="NeedsRestoringAcceptEncoding">
                       <add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+"></add>
                </precondition>
           </preconditions>
   </outboundrules>

By configuring the Inbound and Outbound rules, you are now able to mitigate the 500.52 status code if our backend server was compressing the responses as a result of the client browser sending ‘Accept-Encoding’ headers in the incoming requests.

More information you can refer to this link: https://techcommunity.microsoft.com/t5/iis-support-blog/iis-acting-as-reverse-proxy-where-the-problems-start/ba-p/846259.

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

@SamWu-MSFT Hi, I have already tried that, and also verified that no compression is being used by connecting to the backend web server with telnet to make the request, which will do no automatic decompression of the response.

According to the RFC, "identity" means no encoding.