HTTPS重定向IIS中的偶尔失败

Question

环境信息：

• Windows 2012 R2
• IIS 8
• IIS URL重写模块2 (13/04/2015) 7.2.2
• 乌姆布拉科7.11.1

配置描述

我们有一个Umbraco站点，它绑定到两个主要域名，让我们称它们为sitea.com和siteb.com --这些站点都是相同的源代码&部署，但内容完全不同。在IIS中，站点也绑定到www.sitea.com和www.siteb.com。

此外，我们的网站(S)与LetsEncrypt的所有4个域名安全。

站点应该位于HTTPS上，而且我们还将useSSL的umbraco键设置为true。

<add key="umbracoUseSSL" value="true" />

重写配置

我们已经设置了一些重定向，整个重写配置都粘贴在下面，匿名：

    <rewrite>
            <rules>
                <rule name="Allow LetsEncrypt" patternSyntax="Wildcard" stopProcessing="true">
                    <match url=".well-known/*" />
                    <action type="None" />
                </rule>
                <rule name="Remove WWW" patternSyntax="Wildcard" stopProcessing="false">
                    <match url="*" />
                    <conditions>
                        <add input="{CACHE_URL}" pattern="*://www.*" />
                    </conditions>
                    <action type="Redirect" url="{C:1}://{C:2}" redirectType="Permanent" />
                </rule>
                <rule name="HTTPS" patternSyntax="Wildcard" stopProcessing="false">
                    <match url="*" />
                    <conditions>
                        <add input="{HTTPS}" pattern="off" />
                    </conditions>
                    <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" />
                </rule>
            </rules>
        </rewrite>

总之，有三条规则

1. 一个旁路规则，所以当LetsEncrypt验证~/.众所周知时，它不会被重定向捕获。
2. 重定向，如果您访问www.sitea.com或www.siteb.com，您将被重定向到{ protocol }://sitea.com，这取决于您在哪个协议上输入了站点。
3. 进一步的重定向，它检测HTTPS是否打开，如果没有，则将您重定向到https://{domain}/{path}

问题

有时，正如我们的监视和手动验证所指出的，如果您访问http://sitea.com，那么您将被重定向到https://sitea.com:80。

注意重定向URL上添加了端口80。这会导致站点不加载，因为我们指定的是https，而是命中了http绑定。

如果重置站点的应用程序池，问题将立即自行解决。此问题可以持续几个小时，然后可以自我纠正，但是这可能是由于应用程序池在绝对时间上重置或应用程序请求而引起的(我们尚未对此进行调查)。

在重定向配置中，我看不到任何可能导致这种情况的错误，这是一个只会定期发生的问题。我们在IIS中的同一服务器上有其他网站，具有非常相似的重定向和绑定结构，但它们没有表现出相同的症状。

如果是相关的，在Umbraco中，有两个内容树，每个都绑定到sitea.com和siteb.com。我只在应用程序而不是URL重写配置出现问题时才提到这一点。

以前有人见过这个虫子吗？有简单的解决办法吗？

调整重写规则以包含端口& FRT

根据对我问题的评论的建议，我使用https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/using-failed-request-tracing-to-trace-rewrite-rules启用了FRT

我首先必须将其安装为IIS模块，然后“修复”URL重写模块以获得可用的跟踪选项。我将其配置为响应300-301。

我等待问题再次发生，然后当问题再次发生时，我检查了日志。

我可以看到，在发生故障后，有一个REDIRECT_FROM_CACHE_ACTION作为URL重写数据的一部分，其CachedRedirectedUrl值为https://sitea.com:80/。这解释了为什么在应用程序池重置、重定向输出被缓存和重置清除缓存之前，问题不会自动解决。

检查早期的FRT日志(查找缓存请求的位置)将我引向以下几个方面：

在这里，我们可以看到HTTPS规则计算开始，匹配，但是在替换<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" />中的令牌后得到的重定向URL是https://sitea.com:80 (条目#28，RedirectURL)。

我修改了重写规则，以便HTTPS规则读取

<rule name="HTTPS" patternSyntax="Wildcard" stopProcessing="false">
          <match url="*" />
          <conditions>
            <add input="{HTTPS}" pattern="off" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}:443{REQUEST_URI}" redirectType="Permanent" />
        </rule>

这似乎没有必要，因为当未指定端口时，端口应该是从协议中推断出来的，但可能是URL重写中的错误吗？几天后，出现了最初的问题，这一次为https://sitea.com:80:443/发出重定向(这是一个无效的带有两个端口的重定向).**

编辑1:我已经提取了u7.11.1的源代码，并检查了umbracoUseSSL的使用情况，这似乎只在后台、一些通知和api路由中使用。前端页面呈现不检查此变量，也不尝试https重定向。因此，这表明这个问题是应用程序的上游问题。

编辑2:把我建议的答案和原来的问题合并，因为它没有解决问题(它使问题变得更糟)

Answer 1

服务器变量{HTTP_HOST}包括端口号。您可以尝试使用{SERVER_NAME}，或者编写一个只捕获{HTTP_HOST}变量主机名的regex条件。下面是后者的一个例子。确保trackAllCaptures="true"

<rewrite>
        <rules>
            <rule name="Allow LetsEncrypt" patternSyntax="Wildcard" stopProcessing="true">
                <match url=".well-known/*" />
                <action type="None" />
            </rule>
            <rule name="Remove WWW" patternSyntax="Wildcard" stopProcessing="false">
                <match url="*" />
                <conditions>
                    <add input="{CACHE_URL}" pattern="*://www.*" />
                </conditions>
                <action type="Redirect" url="{C:1}://{C:2}" redirectType="Permanent" />
            </rule>
            <rule name="HTTPS" patternSyntax="Wildcard" stopProcessing="false">
                <match url="*" />
                <conditions trackAllCaptures="true">
                    <add input="{HTTPS}" pattern="off" />
                    <add input="{HTTP_HOST}" pattern="(.*):?\d*" />
                </conditions>
                <action type="Redirect" url="https://{C:1}{REQUEST_URI}" redirectType="Permanent" appendQueryString="false" />
            </rule>
        </rules>
    </rewrite>

还添加了appendQueryString="false"，因为{REQUEST_URI}已经包含查询字符串。