IIS 作为反向代理 - 压缩来自后端服务器的重写响应

Question

我正在实现一个反向代理，用于将请求路由到后端服务器。

功能上一切正常，但是我担心来自后端服务器的所有响应都会在没有压缩的情况下传输到客户端（网络浏览器）。

设置如下：

• 内部域上的后端服务器，公众无法访问。在https://internal.app 上托管一个 Web 应用程序
• 带有 IIS 7.5 的前端 Web 服务器，托管主要公共网站并充当后端服务器的代理。主站点位于https://site.com。

我想以对客户端透明的方式将所有请求路由到 https://site.com/app/WHATEVER 到 https://internal.app/WHATEVER。

我当前的设置基于 URL Rewrite 2.0 和应用程序请求路由 IIS 扩展。一般方法基于以下文章中的指南：

• Setting up a Reverse Proxy using IIS, URL Rewrite and ARR
• Reverse Proxy with URL Rewrite v2 and Application Request Routing

site.com 应用程序的web.config 的相关部分：

<system.webServer>
    <rewrite>
        <rules>
            <rule name="Route the requests for backend app" stopProcessing="true">
                <match url="^app/(.*)" />
                <conditions>
                    <add input="{CACHE_URL}" pattern="^(https?)://" />
                </conditions>
                <action type="Rewrite" url="{C:1}://internal.app/{R:1}" />
                <serverVariables>
                    <set name="HTTP_ACCEPT_ENCODING" value="" />
                </serverVariables>
            </rule>
        </rules>
        <outboundRules>
            <rule name="RewriteBackendAbsoluteUrlsInResponse" preCondition="ResponseIsHtml1">
                <match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script" pattern="^http(s)?://internal.app(\:80)?/(.*)" />
                <action type="Rewrite" value="/app/{R:3}" />
            </rule>
            <rule name="RewriteBackendAbsoluteUrlsInRedirects" preCondition="ResponseIsHtml1">
                <match serverVariable="RESPONSE_LOCATION" pattern="^http(s)?://internal.app(\:80)?/(.*)" />
                <action type="Rewrite" value="/app/{R:3}" />
            </rule>
            <rule name="RewriteBackendRelativeUrlsInResponse" preCondition="ResponseIsHtml1">
                <match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script" pattern="^/(.*)" negate="false" />
                <conditions>
                    <add input="{URL}" pattern="^/app/.*" />
                </conditions>
                <action type="Rewrite" value="/app/{R:1}" />
            </rule>
            <rule name="RewriteBackendRelativeUrlsInRedirects" preCondition="ResponseIsHtml1">
                <match serverVariable="RESPONSE_LOCATION" pattern="^/(.*)" negate="false" />
                <conditions>
                    <add input="{URL}" pattern="^/app/.*" />
                </conditions>
                <action type="Rewrite" value="/app/{R:1}" />
            </rule>
            <preConditions>
                <preCondition name="ResponseIsHtml1">
                    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                </preCondition>
            </preConditions>
        </outboundRules>
    </rewrite>
    <urlCompression dynamicCompressionBeforeCache="false" />
</system.webServer>

问题是，一旦我停止清除HTTP_ACCEPT_ENCODING 服务器变量，每个符合上述规则的请求都会以以下错误结束：HTTP Error 500.52 - URL Rewrite Module Error. Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded ("gzip").

我知道this thread 并且我已按照这些说明进行操作。如上所示，我已经设置了dynamicCompressionBeforeCache="false"，我已经添加了必要的注册表项，并且我确保模块在 IIS 中的顺序正确。

但是，这似乎只有在重写发生在一个 Web 应用程序中时才有效。如果我删除上述规则并添加一个简单的规则（以及相应的出站规则）来重写，例如/x/WHATEVER 到 /WHATEVER，无需清除 HTTP_ACCEPT_ENCODING 即可完美运行 - 规则有效，并且为重写的请求启用了压缩。

但是，一旦我重新添加将响应重写到不同 Web 应用程序的规则，并且我没有清除 HTTP_ACCEPT_ENCODING 标头，就会再次出现相同的错误。

据我了解，如果重写涉及另一个 Web 应用程序，那么可以做什么会受到更多限制。例如。 URL 重写器必须从后端服务器接收未压缩的响应，以便能够使用出站规则对其进行重写。我想在这种情况下清除 HTTP_ACCEPT_ENCODING 是必须的。

但是，我希望由于压缩模块列在模块列表的顶部，因此无论来自何处，都应该压缩最终重写的响应。似乎 IIS 做了一些快捷方式，并绕过压缩模块将响应返回给客户端。或者HTTP_ACCEPT_ENCODING 标头很快就会被删除以完全禁用压缩（不仅在服务器到服务器的通信中）。

最后，我的问题是：有没有办法压缩这些响应？

Answer 1

我自己想通了。

需要做什么才能使其正常工作：

• Accept-Encoding 标头必须在将请求路由到后端服务器之前删除，以便可以使用出站规则重写响应
• 必须通过附加的出站规则恢复标头，以便在将响应发送到客户端之前压缩模块启动时显示标头

我决定这样做：

• 在重写规则中添加一个新的服务器变量来保存客户端发送的原始标头：

  <set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="{HTTP_ACCEPT_ENCODING}" />
  

  （我把它放在清除 HTTP_ACCEPT_ENCODING 变量的行之前）

• 添加新的出站规则：

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

  以及附带的前提条件：

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

到目前为止就像一个魅力。

Answer 2

要在仍然保留 gzip 压缩响应的同时解决原始发帖者的问题，只需执行以下操作：

1. 更新您面向公众的网络服务器上的注册表，如下所示：

   一个。对于 64 位网站，在具有管理员权限的命令控制台中运行以下命令：reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0

   b.对于 32 位网站，在具有管理员权限的命令控制台中运行以下命令：reg add HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432node\Microsoft\Inetstp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0

2. 重置 IIS

3. 禁用静态压缩

   一个。为此，我插入了以下我的网络配置：<urlCompression doStaticCompression="false" doDynamicCompression="true" dynamicCompressionBeforeCache="false" />

4. 在 IIS 管理器的服务器节点中，双击Modules 图标，然后在右侧，单击“查看有序列表”并验证您的静态/动态压缩模块是否朝向顶部和 URL重写模块是朝向底部的

请注意

我看到网上有很多解决这个问题的方法，其中 HTTP_CONTENT_TYPE 请求标头作为 URL 重写规则的一部分被清除（包括此页面上的答案）。应该知道，虽然这确实解决了 500.52 错误的原始问题，但响应上的 gzip 压缩是 REMOVED。这可能是我们想要的结果，但如果需要 gzip 压缩，上述解决方案就可以解决问题

Answer 3

PS：以下解决方案仅在您可以控制您的应用服务器时才有效。

它基本上是让 Web 服务器进行压缩，并让应用服务器完成应用程序应该做的重任（不压缩）。

如果您在应用服务器上禁用压缩，您从应用服务器获得的响应是​​未压缩的。在 Web 服务器上，您应该启用压缩，因此 Web 服务器在响应客户端（浏览器）时将遵循 HTTP 标头“Accept-Encoding: gzip,deflate”。

此配置将卸载应用服务器上的 CPU，但会增加您的 Web 服务器和应用服务器之间的网络流量。如果您在内部网络上，它不会对性能产生太大影响。

Answer 4

只需在重写规则中添加“serverVariables”标签就可以了：

<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>