需要帮助了解 IIS 管道中请求的行为

Question

最近，我正在处理使用 IIS 的 Azure 托管 ASP .NET Core 应用程序上不需要的重定向的案例。我们遇到包含两个 HTTP/HTTPS 前缀的请求的问题。我输入了失败请求跟踪日志并看到了这一点（查看 RequestURL 值）：

后来被缩短为：

任何人都可以帮助我理解为什么会发生这种情况？它发生在请求进入重写管道之前，即使如此，我们也没有任何可能导致它的重写规则。

Answer 1

“我们遇到包含两个 HTTP/HTTPS 前缀的请求”

• 首先，它们不被称为“HTTP/HTTPS 前缀”——它们被称为 URI 方案。
• 其次，您在那里记录的请求实际上并不包含两个 URI 方案；我来解释一下...

但在此之前，请快速阅读通读当前 IETF 规范的第 3 部分，该规范定义了 URI 的含义，并学习其语法组件的术语。

• 日志中的

  /http:/wp.pl

  文本看起来像是新URI的开头，当脱离上下文时，它仍然被解释为传入请求的路径组件，因为这就是网络服务器编程要做的事情。
  • 有趣的事实：HTTP 请求不（通常）包含请求的完全限定的 URI 表示（如果它们隐藏在反向代理后面，那么它们可能会，并且这也适用于您在 Azure 应用服务上，但无论如何）。
    • 在 HTTP 请求中，没有 URI 方案 或“协议”替代：服务器无论如何都根据传入端口号和 TLS 交换知道请求是来自

      http:

      还是

      https:

      。
    • URI 的 authority 部分 将在

      Host:

      标头中单独发送。
    • 因此，只有 path 部分 和可选的 query 部分 在 HTTP

      GET /path/goes/here

      部分中发送。
    • 虽然任何

      #fragment

      部分根本不会发送到服务器。

因此，在这种情况下，您在那里记录的请求完全有效，因为绝对 URI 或“根”URI 的路径组件中不禁止使用冒号（无论是否采用百分比编码）。 只有相对 URI 路径不能在其初始路径段中包含

:

，因为这会导致它们的格式不明确。