c# - ASP.NET Core 中的 HttpRequest.Path 和 HttpRequest.PathBase 有什么区别？

Question

详情如下:https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.httprequest?view=aspnetcore-3.0 , ASP.NET Core 的 HttpRequest类(class)包括 Path和 PathBase特性。

这两个属性有什么区别？每一个是做什么用的？ PathBase是什么意思?同时拥有 Path 有什么意义？和一个 PathBase ?

我找不到任何详细说明为什么会这样的文档 - 有什么想法吗？

Answer 1

在 ASP.NET 核心中有一个称为路径基础的概念。基本思想很容易理解:路径基被认为是 Web 应用程序的所有传入请求的路径的固定前缀。默认情况下，路径基数被认为是空字符串。

这意味着，默认情况下，当请求进入您的应用程序时，请求 URL 的所有路径部分都将映射到 Path HttpRequest 的属性(property)对象和 PathBase属性将设置为 string.empty .

例如，考虑一个在本地机器上运行并监听端口 3000 的 asp.net 核心应用程序。 .假设您使用原始 kestrel Web 服务器运行应用程序(因此不涉及反向代理，请求直接到达 kestrel)。

当您请求 URL 时 http://localhost:3000/foo/bar然后是 HttpRequest对象将具有以下属性:

HttpRequest.Path将设置为 /foo/bar

HttpRequest.PathBase将设置为 string.empty

当您决定使用 Windows 应用服务在 Azure 上托管您的应用程序时，您会遇到同样的情况。

在此托管方案中，ASP.NET 核心 Web 应用程序的默认设置在 内执行。同 进程作为 IIS 工作进程。这基本上意味着只涉及一个过程；再次没有反向代理，根本不使用 kestrel Web 服务器:请求由 IIS 直接处理(如果您有兴趣，可以找到一些详细信息 here)。

在这种情况下，您的应用程序的公共(public) URL 将类似于 https://my-application.azurewebsites.net .当您浏览到 URL https://my-application.azurewebsites.net/foo/bar 时，传入http请求的情况如下:

HttpRequest.Path将设置为 /foo/bar

HttpRequest.PathBase将设置为 string.empty

同样，和以前一样，路径基数是空字符串。

在不同的托管方案中，您可以决定使用虚拟目录公开您的应用程序。

例如，您可能决定使用安装了 IIS 的 Windows 虚拟机在您自己的数据中心托管 asp.net 核心 Web 应用程序。在这种情况下，您可能在 IIS 中有一个现有网站，并且您想在该网站下创建一个具有适当别名的虚拟应用程序。同样在这种情况下，如上面针对 azure windows 应用程序服务所解释的那样，不涉及反向代理，并且根本不使用 kestrel Web 服务器:请求由 IIS 工作进程 ( in process hosting model ) 直接处理。

假设您网站的公共(public) URL 是 https://sample-application.contoso.net并且您选择了 sample-alias作为虚拟应用程序的别名。这意味着对您的 asp.net 核心 Web 应用程序的所有请求都将有一个以 sample-alias 开头的路径部分。 .例如，当您需要应用程序的主页时，您将浏览到 https://sample-application.contoso.net/sample-alias。 .

在这种情况下，当您请求 URL https://sample-application.contoso.net/sample-alias/foo/bar 时, HttpRequest您的应用程序中的对象将通过以下方式完成:

HttpRequest.Path将设置为 /foo/bar

HttpRequest.PathBase将设置为 sample-alias

由于 ASP.NET 核心应用程序的默认 Web 主机的构建方式，这种涉及 IIS 虚拟应用程序的场景开箱即用，中间件管道知道所有传入 HTTP 请求的公共(public)前缀，并且能够将路径基数设置为 sample-alias以及传入请求路径剩余部分的路径属性(在我上面的示例中为 /foo/bar)。

根据经验，当您想使用 IIS 托管 ASP.NET 核心 Web 应用程序时，您可以认为无需任何其他配置即可正常工作。对于路径基本属性也是如此(检查 here 以验证请求基本路径是在应用程序中自动设置的)。

作为最后一个示例，请考虑在 Linux 机器上托管您的应用程序，使用 nginx 作为反向代理。在这种情况下，您的应用程序将在 kestrel Web 服务器内执行，但不会直接暴露给公共(public)互联网。暴露给公共(public)互联网的是 nginx Web 服务器，它将传入的 HTTP 请求路由到 kestrel Web 服务器(您的应用程序在其中执行)。您可以决定配置您的 nginx，以便所有以前缀 /awesome-application 开头的请求。将路由到您的 asp.net 核心 Web 应用程序。

例如，假设在 URL https://ingress.contoso.net 处将 nginx 暴露给公共(public)互联网。 : 在这种情况下，如果您想请求应用程序的主页，您需要浏览到 https://ingress.contoso.net/awesome-application/ .

在这种情况下 您无法获得 awesome-application免费请求路径基础 (默认情况下，kestrel 不知道它，它认为请求路径基为 string.empty )。

为了让 kestrel 知道请求路径基础，您需要使用 UsePathBaseMiddleware作为中间件管道中的第一项。

如果您需要有关此案例的更多详细信息，请关注 this documentation另见 this stackoverflow question .