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

Question

如此处详细说明：https : //docs.microsoft.com/zh-cn/dotnet/api/microsoft.aspnetcore.http.httprequest?view=aspnetcore-3.0，ASP.NET Core的HttpRequest类同时包含Path和PathBase属性。

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

我找不到任何详细说明其原因的文档-有任何想法吗？

Answer 1

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

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

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

当您请求URL时，http://localhost:3000/foo/bar该HttpRequest对象将具有以下属性：

• HttpRequest.Path 将设置为 /foo/bar
• HttpRequest.PathBase 将设置为 string.empty

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

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

在这种情况下，您的应用程序的公共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工作进程（在进程托管模型中）处理。

假设您的网站的公共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请求的通用前缀，并且能够将路径基础设置为sample-alias，将路径属性设置为传入请求路径的其余部分（/foo/bar在上面的示例中）。

根据经验，当您想使用IIS承载ASP.NET核心Web应用程序时，无需任何其他配置即可正常运行。路径基本属性也是如此（在此处检查以确认请求基本路径是在stratup中的应用程序内部自动设置的）。

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

举例来说，假设将nginx通过URL公开到公共互联网https://ingress.contoso.net：在这种情况下，如果您想请求应用程序的主页，则需要浏览到https://ingress.contoso.net/awesome-application/。

在这种情况下，您将无法awesome-application免费获取请求路径库（默认情况下，kestrel不会意识到这一点，它认为请求路径库为string.empty）。

为了使茶est了解请求路径的基础，您需要将UsePathBaseMiddleware用作中间件管道中的第一项。

如果您需要有关这种情况的更多详细信息，请遵循此文档，并参阅此stackoverflow问题。