In ASP.NET Core gibt es dieses Konzept, das als Pfadbasis bezeichnet wird . Die Grundidee ist leicht zu verstehen: Die Pfadbasis wird als festes Präfix für den Pfad aller eingehenden Anforderungen an Ihre Webanwendung betrachtet. Standardmäßig wird die Pfadbasis als leere Zeichenfolge betrachtet.
Dies bedeutet, dass beim Eingeben einer Anforderung in Ihre Anwendung standardmäßig der gesamte Pfadabschnitt der URL der Anforderung der PathEigenschaft des HttpRequestObjekts zugeordnet und die PathBaseEigenschaft auf festgelegt wirdstring.empty .
Stellen Sie sich als Beispiel eine asp.net-Kernanwendung vor, die auf Ihrem lokalen Computer ausgeführt wird und den Port überwacht 3000. Angenommen, Sie führen die Anwendung über den unformatierten Turmfalken-Webserver aus (es ist also kein Reverse-Proxy beteiligt, Anforderungen gehen direkt bei Turmfalke ein).
Wenn Sie die URL anfordern, http://localhost:3000/foo/barhat das HttpRequestObjekt die folgenden Eigenschaften:
HttpRequest.Path wird auf gesetzt /foo/barHttpRequest.PathBase wird auf gesetzt string.empty
Die gleiche Situation tritt auf, wenn Sie Ihre Anwendung mithilfe eines Windows-App-Dienstes auf Azure hosten.
In diesem Hosting-Szenario wird die Standardeinstellung für eine ASP.NET-Kernwebanwendung im selben Prozess wie der IIS-Arbeitsprozess ausgeführt. Dies bedeutet im Grunde, dass nur ein Prozess beteiligt ist; Auch hier gibt es keinen Reverse-Proxy und der Kestrel-Webserver wird überhaupt nicht verwendet: Die Anfrage wird direkt von IIS bearbeitet (einige Details finden Sie hier, wenn Sie interessiert sind).
In diesem Fall lautet die öffentliche URL für Ihre Anwendung ungefähr so https://my-application.azurewebsites.net. Wenn Sie zur URL navigieren https://my-application.azurewebsites.net/foo/bar, ist die Situation für die eingehende http-Anforderung wie folgt:
HttpRequest.Path wird auf gesetzt /foo/barHttpRequest.PathBase wird auf gesetzt string.empty
Auch hier ist die Pfadbasis nach wie vor die leere Zeichenfolge.
Es gibt verschiedene Hosting-Szenarien, in denen Sie Ihre Anwendung mithilfe eines virtuellen Verzeichnisses verfügbar machen können.
Sie können beispielsweise entscheiden, die asp.net-Kernwebanwendung in Ihrem eigenen Rechenzentrum zu hosten, indem Sie eine virtuelle Windows-Maschine verwenden, auf der IIS installiert ist. In diesem Fall verfügen Sie möglicherweise über eine vorhandene Website in IIS und möchten eine virtuelle Anwendung mit einem geeigneten Alias unter dieser Website erstellen. Auch in diesem Szenario ist, wie oben für den Azure Windows-App-Dienst erläutert, kein Reverse-Proxy beteiligt, und der Turmfalken-Webserver wird überhaupt nicht verwendet: Die Anforderung wird direkt vom IIS-Worker-Prozess ( im Prozess-Hosting-Modell ) verarbeitet.
Angenommen, die öffentliche URL Ihrer Website lautet https://sample-application.contoso.netund Sie haben die sample-aliasals Alias für die virtuelle Anwendung ausgewählt. Dies bedeutet, dass alle Anforderungen an Ihre asp.net-Kernwebanwendung einen Pfadabschnitt haben, der mit beginnt sample-alias. Wenn Sie beispielsweise die Startseite Ihrer Anwendung benötigen, navigieren Sie zu https://sample-application.contoso.net/sample-alias.
In diesem Fall https://sample-application.contoso.net/sample-alias/foo/barwird das HttpRequestObjekt in Ihrer Anwendung auf folgende Weise ausgeführt, wenn Sie die URL anfordern :
HttpRequest.Path wird auf gesetzt /foo/barHttpRequest.PathBase wird auf gesetzt sample-alias
Aufgrund der Art und Weise, wie der Standard-Webhost für eine ASP.NET-Kernanwendung erstellt wird, funktioniert dieses Szenario mit virtuellen IIS-Anwendungen sofort, und die Middleware-Pipeline kennt das gemeinsame Präfix für alle eingehenden HTTP-Anforderungen und kann dies Setzen Sie die Pfadbasis auf sample-aliasund die Pfadeigenschaft auf den verbleibenden Teil des Pfads der eingehenden Anforderung ( /foo/barin meinem obigen Beispiel).
Als Faustregel können Sie berücksichtigen, dass eine ASP.NET-Kernwebanwendung ohne zusätzliche Konfigurationen einwandfrei funktioniert, wenn Sie sie mithilfe von IIS hosten möchten. Dies gilt auch für die Eigenschaft path base (überprüfen Sie hier , ob der Pfad der Anforderungsbasis in Ihrer Anwendung beim Stratup automatisch festgelegt wird).
Als letztes Beispiel sollten Sie Ihre Anwendung auf einem Linux-Computer hosten, indem Sie nginx als Reverse-Proxy verwenden. In diesem Fall wird Ihre Anwendung auf dem Turmfalken-Webserver ausgeführt, jedoch nicht direkt dem öffentlichen Internet ausgesetzt. Das öffentliche Internet ist der Nginx-Webserver, der die eingehenden HTTP-Anforderungen an den Kestrel-Webserver weiterleitet (auf dem Ihre Anwendung ausgeführt wird). Sie können Ihren Nginx so konfigurieren, dass alle Anforderungen, die mit dem Präfix beginnen /awesome-application, an Ihre asp.net-Kernwebanwendung weitergeleitet werden.
Angenommen, Sie stellen nginx unter der URL dem öffentlichen Internet zur Verfügung https://ingress.contoso.net: In diesem Fall müssen Sie navigieren, wenn Sie die Startseite Ihrer Anwendung anfordern möchten https://ingress.contoso.net/awesome-application/.
In diesem Fall können Sie die awesome-applicationAnforderungspfadbasis nicht kostenlos abrufen (standardmäßig ist sich Turmfalke dessen nicht bewusst und betrachtet die Anforderungspfadbasis als solche string.empty).
Um Turmfalke auf die Basis des Anforderungspfads aufmerksam zu machen, müssen Sie die UsePathBaseMiddleware als erstes Element in Ihrer Middleware-Pipeline verwenden.
Wenn Sie weitere Details für diesen Fall benötigen, befolgen Sie diese Dokumentation und lesen Sie auch diese Frage zum Stapelüberlauf .
MapVerwendung werden die übereinstimmendenHttpRequest.PathPfadsegmenteHttpRequest.PathBaseaus jeder Anforderung entfernt und an diese angehängt . .