此处详细介绍：https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.httprequest?view=aspnetcore-3.0，ASP.NET Core的HttpRequest类同时包含Path和PathBase属性。
这两个属性有什么区别？每个人都有什么用？ PathBase是什么意思？同时拥有Path和PathBase有什么意义？
我找不到详细说明其原因的文档-有任何想法吗？
答案 0 :(得分：6)
在ASP.NET核心中，有一个称为路径库的概念。基本思想很容易理解：路径基础被认为是Web应用程序中所有传入请求的路径的固定前缀。默认情况下，路径库被认为是空字符串。
这意味着，默认情况下，当请求进入您的应用程序时，请求URL的所有路径部分都将映射到Path对象的HttpRequest属性和{ {1}}属性将设置为PathBase 。
以一个示例为例，在您的本地计算机上运行一个asp.net核心应用程序并监听端口string.empty。假设您正在使用原始的kestrel Web服务器运行应用程序（因此不涉及反向代理，请求将直接到达kestrel）。
当您请求URL 3000时，http://localhost:3000/foo/bar对象将具有以下属性：
HttpRequest将设置为HttpRequest.Path /foo/bar将设置为HttpRequest.PathBase 当您决定使用Windows应用程序服务将应用程序托管在Azure上时，也会遇到相同的情况。
在此托管方案中，ASP.NET核心Web应用程序的默认值与IIS工作进程在相同进程内执行。这基本上意味着只涉及一个过程。再次没有反向代理，并且根本不使用kestrel Web服务器：该请求直接由IIS处理（如果您有兴趣，可以here找到一些详细信息）。
在这种情况下，您的应用程序的公共URL将类似于string.empty。当您浏览到URL https://my-application.azurewebsites.net时，传入的HTTP请求的情况如下：
https://my-application.azurewebsites.net/foo/bar将设置为HttpRequest.Path /foo/bar将设置为HttpRequest.PathBase 同样，路径基础是空字符串。
在不同的托管方案中，您可以决定使用虚拟目录公开应用程序。
例如，您可以决定使用安装了IIS的Windows虚拟机在自己的数据中心中托管asp.net核心Web应用程序。在这种情况下，您可能在IIS中有一个现有的网站，并且您想在该网站下创建一个具有适当别名的虚拟应用程序。再次在这种情况下，如上面针对azure Windows应用服务所述，不涉及反向代理并且完全不使用kestrel Web服务器：该请求直接由IIS工作进程（in process hosting model）处理。
假设您网站的公共URL为string.empty，并且您已选择https://sample-application.contoso.net作为虚拟应用程序的别名。这意味着对asp.net核心Web应用程序的所有请求都将包含一个以sample-alias开头的路径部分。例如，当您需要应用程序的主页时，将浏览至sample-alias。
在这种情况下，当您请求URL https://sample-application.contoso.net/sample-alias时，应用程序中的https://sample-application.contoso.net/sample-alias/foo/bar对象将通过以下方式完成：
HttpRequest将设置为HttpRequest.Path /foo/bar将设置为HttpRequest.PathBase 由于构建ASP.NET核心应用程序的默认Web主机的方式，这种涉及IIS虚拟应用程序的方案开箱即用，并且中间件管道知道所有传入HTTP请求的通用前缀，并且能够将路径基础设置为sample-alias，并将path属性设置为传入请求路径的其余部分（在上面的示例中为sample-alias）。
根据经验，当您想使用IIS承载ASP.NET核心Web应用程序时，无需任何其他配置即可正常运行。路径基本属性也是如此（请检查here以确认是否在应用程序内部自动设置了请求基本路径）。
作为最后一个示例，请考虑使用nginx作为反向代理将应用程序托管在Linux计算机上。在这种情况下，您的应用程序将在Kestrel Web服务器中执行，但不会直接暴露给公共互联网。暴露给公共互联网的是Nginx Web服务器，它将传入的HTTP请求路由到Kestrel Web服务器（执行应用程序的地方）。您可以决定配置nginx，以便将所有以前缀/foo/bar开头的请求都路由到asp.net核心Web应用程序。
作为示例，假设将nginx通过URL /awesome-application公开到公共互联网：在这种情况下，如果要请求应用程序的主页，则需要浏览到https://ingress.contoso.net。
在这种情况下，您无法免费获得https://ingress.contoso.net/awesome-application/请求路径库（默认情况下，kestrel并不知道它，因此它认为请求路径库为{{ 1}}）。
为了使茶est了解请求路径的基础，您需要使用UsePathBaseMiddleware作为中间件管道中的第一项。
如果您需要有关此案例的更多详细信息，请遵循this documentation，另请参见this stackoverflow question。