ASP.NET CoreのHttpRequest.PathとHttpRequest.PathBaseの違いは何ですか？

詳細については、https：//docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.httprequest？view = aspnetcore-3.0をご覧ください。ASP.NETCoreのHttpRequestクラスには、PathとPathBaseプロパティの両方が含まれています。

これら2つのプロパティの違いは何ですか？それぞれ何に使用されていますか？の意味はPathBase何ですか？a Pathとaの両方を持つことの意味は何PathBaseですか？

なぜそれが現状のままであるかを詳しく説明したドキュメントが見つかりません-アイデアはありますか？

ASP.NETコアには、パスベースと呼ばれるこの概念があります。基本的な考え方は非常に簡単に理解できます。パスベースは、Webアプリケーションへのすべての受信リクエストのパスの固定接頭辞と見なされます。デフォルトでは、パスベースは空の文字列と見なされます。

つまり、デフォルトでは、リクエストがアプリケーションに入ると、リクエストのURLのすべてのパス部分がオブジェクトのPathプロパティにマッピングされHttpRequest、PathBaseプロパティがに設定されstring.emptyます。

例として、ローカルマシンで実行され、ポートをリッスンするasp.netコアアプリケーションを考えます3000。生のケストレルWebサーバーを使用してアプリケーションを実行しているとします（したがって、リバースプロキシが含まれていないため、リクエストは直接ケストレルに到着します）。

URLをリクエストするとhttp://localhost:3000/foo/bar、HttpRequestオブジェクトには次のプロパティが含まれます。

• HttpRequest.Path に設定されます /foo/bar
• HttpRequest.PathBase に設定されます string.empty

Windowsアプリサービスを使用して、Azureでアプリケーションをホストする場合も同じ状況になります。

このホスティングシナリオでは、ASP.NETコアWebアプリケーションのデフォルトがIISワーカープロセスと同じプロセス内で実行されています。これは基本的に、プロセスが1つしかないことを意味します。この場合も、リバースプロキシはなく、ケストレル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に既存のWebサイトがあり、そのWebサイトの下に適切なエイリアスを持つ仮想アプリケーションを作成したいとします。このシナリオでも、上でazure windowsアプリサービスについて説明したように、リバースプロキシは含まれておらず、ケストレルWebサーバーはまったく使用されていません。リクエストはIISワーカープロセス（プロセスホスティングモデル）によって直接処理されます。

Webサイトのパブリック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アプリケーションが正常に機能すると考えることができます。これは、パスの基本プロパティにも当てはまります（ここをチェックして、リクエストの基本パスがアプリケーション内のストラトアップで自動的に設定されることを確認してください）。

最後の例として、nginxをリバースプロキシとして使用して、Linuxマシンでアプリケーションをホストすることを検討してください。この場合、アプリケーションはケストレルWebサーバー内で実行されますが、公共のインターネットに直接公開されることはありません。パブリックインターネットに公開されているのは、受信HTTPリクエストをケストレルWebサーバー（アプリケーションが実行される場所）にルーティングするnginx Webサーバーです。接頭辞で始まるすべてのリクエストが/awesome-applicationasp.netコアWebアプリケーションにルーティングされるように、nginxを構成することを決定できます。

例として、nginxをURLでパブリックインターネットに公開するとしますhttps://ingress.contoso.net。この場合、アプリケーションのホームページをリクエストする場合は、にアクセスする必要がありますhttps://ingress.contoso.net/awesome-application/。

この場合、awesome-applicationリクエストパスベースを無料で取得することはできません（デフォルトでは、ケストレルはそれを認識せず、リクエストパスベースをと見なしますstring.empty）。

kestrelにリクエストパスベースを認識させるには、ミドルウェアパイプラインの最初のアイテムとしてUsePathBaseMiddlewareを使用する必要があります。

このケースの詳細が必要な場合は、このドキュメントに従って、このstackoverflow質問も参照してください。