IIS作为反向代理 - 来自后端服务器重写响应的COM pression [英] IIS as a reverse proxy - compression of rewritten response from backend server

查看:377
本文介绍了IIS作为反向代理 - 来自后端服务器重写响应的COM pression的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我实现一个反向代理的请求路由到后端服务器。

I am implementing a reverse proxy for routing requests to a backend server.

在功能一切正常,但是我很担心,从后端服务器的所有响应,而不COM pression传输到客户端(网页浏览器)。

Functionally everything works correctly, however I am concerned that all responses from the backend server are transferred to the client (web browser) without compression.

的设置如下:


  • 后端服务器,供公众无法访问,在内部域。主机上的 https://internal.app <​​/ code>
  • Web应用程序
  • 与IIS 7.5前端Web服务器,托管主要的公共网站,充当后台服务器的代理。主要站点是位于 https://site.com

  • Backend server, not accessible for public, on an internal domain. Hosts a web application on https://internal.app
  • Front web server with IIS 7.5, hosting the main public website and acting as a proxy for the backend server. The main site is at https://site.com.

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

I want to route all requests to https://site.com/app/WHATEVER to https://internal.app/WHATEVER in a way that is transparent to clients.

我目前的设置是基于URL重写2.0和应用程序请求路由IIS扩展。一般的方法是根据指引从下面的文章:

My current setup is based on URL Rewrite 2.0 and Application Request Routing IIS extensions. The general approach is based on guidelines from the following articles:

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

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

The relevant section of web.config of the site.com app:

<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错误500.52 - URL重写模块错误。
出站重写规则不能被应用在HTTP响应的内容是EN codeD(gzip的)。

The problem is that as soon as I stop clearing the HTTP_ACCEPT_ENCODING server variable, each request which matches the above rule ends with the following error: HTTP Error 500.52 - URL Rewrite Module Error. Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded ("gzip").

我知道这个线程和我按照这些指令。我已设置 dynamicCom pressionBeforeCache =FALSE如上面可以看出,我已经添加了必要的注册表项,我已经放心,模块是在正确的顺序IIS。

I am aware of this thread and I have followed those instructions. I have set dynamicCompressionBeforeCache="false" as can be seen above, I have added the necessary registry entry and I have assured that the modules are in correct order in IIS.

不过,这似乎只只有重写一台Web应用程序中发生的工作。如果我删除上面的规则,并添加一个简单的(以及相应的出站规则)来重写例如 / X /不管只是 /不管,所有完美的作品,而不需要清除 HTTP_ACCEPT_ENCODING - 规则工作和COM pression为重写请求启用

However, this only seems to work only if the rewriting happens within one web app. If I remove the above rules and add a simple one (and respective outbound rules) to rewrite e.g. /x/WHATEVER to just /WHATEVER, all works perfectly without a need to clear HTTP_ACCEPT_ENCODING - the rule works and compression is enabled for the rewritten requests.

但只要我重新添加我的规则,该规则重写到不同的Web应用程序的响应,我不清除 HTTP_ACCEPT_ENCODING 头,出现同样的错误试。

But as soon as I re-add my rule which rewrites the response to a different web app, and I don't clear the HTTP_ACCEPT_ENCODING header, the same error appears again.

据我了解,如果重写涉及到另一个Web应用程序,还有什么可以做更多的约束。例如。 URL重写必须接收来自后端服务器为了一个uncom pressed响应能够使用出站规则重写一遍。我猜结算 HTTP_ACCEPT_ENCODING 在这种情况下是因为这是必须的。

From what I understand, if the rewriting involves another web app, there are more constraint on what can be done. E.g. URL rewriter must receive an uncompressed response from the backend server in order to be able to rewrite it using the outbound rules. I guess clearing HTTP_ACCEPT_ENCODING in this scenario is a must because of this.

不过,我预计,由于COM pression模块的模块列表的顶部列出,最后重写反应应该是COM pressed不管它源于。看来IIS使一些快捷键和返回给客户端绕过COM pression模块的响应。或 HTTP_ACCEPT_ENCODING 头被移除很快完全禁用COM pression(不仅在服务器到服务器的通信)。

However, I would expect that since the compression module is listed on top of the modules list, the final rewritten response should be compressed no matter where it originated from. It seems IIS makes some shortcuts and returns the response to the client bypassing the compression module. Or the HTTP_ACCEPT_ENCODING header is removed soon enough to completely disable compression (not only in server-to-server communication).

所以最后,我的问题是:有没有办法对COM preSS这些反应

So finally, my question is: is there a way to compress those responses?

推荐答案

我已经想通了自己。

什么需要做才能得到它的工作:

What needs to be done to get it working:


  • 的Accept-Encoding 头必须将请求路由到后端服务器之前被删除,从而使响应可以使用出站规则被改写

  • 头必须由附加的伴随站规则恢复,因此,它是present当在之前的响应发送到客户端
  • 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

我已经决定做这样的:


  • 新服务器变量添加到重写规则来保存客户端发送的,他原标题:

  • 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}" />

(我把它放在哪个清除 HTTP_ACCEPT_ENCODING 变量前行)

添加一个新的出站规则:

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>

和一个伴随precondition:

and an accompanying precondition:

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


工程就像一个魅力至今。

Works like a charm so far.

这篇关于IIS作为反向代理 - 来自后端服务器重写响应的COM pression的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆