4 回答
我自己已经弄清楚了。
需要做些什么才能使其正常工作:
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>
到目前为止,它就像一个魅力。
要在保留 gzip 压缩响应的同时解决原始发布者的问题,只需执行以下操作:
更新您面向公众的 Web 服务器上的注册表,如下所示:
一个。对于 64 位网站,在具有管理员权限的命令控制台中运行以下命令:
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0
湾。对于 32 位网站,在具有管理员权限的命令控制台中运行以下命令:
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432node\Microsoft\Inetstp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0
重置 IIS
禁用静态压缩
一个。为此,我插入了以下我的网络配置:
<urlCompression doStaticCompression="false" doDynamicCompression="true" dynamicCompressionBeforeCache="false" />
在 IIS 管理器的服务器节点中,双击
Modules
图标,然后在右侧,单击“查看有序列表”并确认您的静态/动态压缩模块朝上,URL 重写模块朝下
请注意
我看到很多关于这个问题的解决方案在网络上浮动,其中 HTTP_CONTENT_TYPE 请求标头作为 URL 重写规则的一部分被清除(包括此页面上的答案)。应该知道,虽然这确实解决了 500.52 错误的原始问题,但响应上的 gzip 压缩是REMOVED。这可能是理想的结果,但如果需要 gzip 压缩,上述解决方案将起到作用
PS:以下解决方案仅在您可以控制应用服务器的情况下才有效。
它基本上是让 Web 服务器进行压缩,并让应用程序服务器完成应用程序应该做的重任(不压缩)。
如果您在应用服务器上禁用压缩,您从应用服务器获得的响应是未压缩的。在 Web 服务器上,您应该启用压缩,因此 Web 服务器将在响应客户端(浏览器)时遵守 HTTP 标头“Accept-Encoding: gzip,deflate”。
此配置将卸载应用服务器上的 CPU,但会增加 Web 服务器和应用服务器之间的网络流量。如果您在内部网络上,它不会对性能产生太大影响。
只需在重写规则中添加“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>