![URL 重写未正确触发](https://linux22.com/image/712728/URL%20%E9%87%8D%E5%86%99%E6%9C%AA%E6%AD%A3%E7%A1%AE%E8%A7%A6%E5%8F%91.png)
ApplicationHost.config
我在 IIS Root ( )配置了一个 URL 重写规则,该规则重定向www.example.com
到 HTTPS。URL 重写配置在我们托管的公共负载均衡器后面的 IIS 实例上设置,我们的托管提供商在其中安装了 SSL。负载均衡器为我们提供了一个X-Forwarded-Proto
标头,用于设置http
原始请求是否为 HTTP 以及https
原始请求是否为 HTTPS。
Url Rewrite 配置如下:
Pattern: .*
Conditions: Match All
Input |Type |Pattern
-------------------------------------------------------------
{HTTP_HOST} |Matches the Pattern |www.example.com
{HTTP_X_Forwarded_Proto}|Matches the Pattern |^http$
Action:
Redirect to URL: https://{HTTP_HOST}{REQUEST_PATH}
Redirect Type : 302
问题是,我们在 Web 服务器本身中安装了 powershell 脚本,用于检查网站是否可用[System.Net.WebRequest]::Create($siteUrl)
。该脚本大多数情况下会报告 HTTP 200(正常),但有时会失败并出现 404 HTTP 错误。由于 PowerShell 脚本是在本地执行的,因此它不应该有标头X-Forwarded-Proto
,也不会被 IIS 收到 404。
是否有可能 URL Rewrite 在不应该触发的时候被触发?
答案1
我建议启用失败请求跟踪,因为它是一个强大的工具,可以查看模块(包括 URL 重写模块)如何处理请求。如果没有它,目前这只是我的猜测。
这是我的猜测:这取决于 IIS 服务器本身上配置的主机文件和/或 DNS 服务器。但是,即使在本地运行,www.example.com 也可能解析回负载平衡器的 IP,并且请求可能通过负载平衡器返回,因此具有 X-Forwarded-Proto 标头。我们可以通过失败请求跟踪查看标头是否存在。
笔记(主要是因为我的强迫症):我建议将模式从 www.example.com 更改为 www(backslash).example(backslash).com,以便告诉 URL 重写点 (.) 是文字点,而不是通配符点。将 (backslash) 替换为实际字符。看来 SO 正在帮我清理字符。