IIS-URL-Umschreibung und ASP.NET-Routing
von Ruslan Yakushev
Mit der Veröffentlichung des URL-Rewrite-Moduls für IIS und der Einbeziehung von ASP.NET-Routing in .NET Framework 4 gab es viele Fragen von ASP.NET-Entwicklern und -Entwicklerinnen dazu, wie diese beiden Features miteinander zusammenhängen und wann sie jeweils verwendet werden sollten. In diesem Dokument werden die Unterschiede zwischen diesen beiden Technologien beschrieben. Außerdem enthält es Leitfäden für die Webentwicklung, wann die IIS-URL-Umschreibung und wann das ASP.NET-Routing verwendet werden sollte.
Aus einer allgemeinen Perspektive scheinen diese Technologien sehr ähnliche Funktionen zu bieten – beide stellen Ihren Webanwendungen benutzerfreundliche und suchmaschinenfreundliche URLs bereit. Es gibt jedoch grundlegende Unterschiede zwischen diesen beiden Technologien, die wichtig sind, um die richtige Entscheidung darüber zu treffen, was für Ihre Webanwendung verwendet werden soll. Um diese Unterschiede zu verstehen, wird zunächst erläutert, wie IIS-URL-Umschreibung und ASP.NET-Routing funktionieren.
IIS-URL-Umschreibung
Die Grundidee der URL-Umschreibung ist kein neues Konzept. Es wurde vor etwa einem Jahrzehnt auf Apache-Webservern eingeführt. Seitdem hat es sich als sehr nützliches Tool für die Webserververwaltung und Webentwicklung bewährt. Viele beliebte Anwendungen, die auf Apache gehostet werden, nutzen mittlerweile URL-Umschreibungen, um Unterstützung für „saubere“ URLs zu bieten.
Das Konzept der URL-Umschreibung ist einfach. Wenn ein Client eine Anforderung für eine bestimmte URL an den Webserver sendet, analysiert das URL-Rewrite-Modul die angeforderte URL und ändert sie in eine andere URL auf demselben Server. Das URL-Rewrite-Modul wird früh in der Anforderungsverarbeitungspipeline ausgeführt und ändert die angeforderte URL, bevor der Webserver entscheidet, welcher Handler für die Verarbeitung der Anforderung verwendet werden soll. Der Handler, der basierend auf der umgeschriebenen URL ausgewählt wird, verarbeitet die Anforderung und generiert eine Antwort, die an den Webbrowser zurückgesendet wird. Der anfordernde Client sieht nie die umgeschriebene URL – aus Clientsicht hat er eine Antwort von der ursprünglichen URL erhalten.
In Bezug auf die IIS-Architektur wird dieser Prozess durch das folgende Diagramm dargestellt:
Das URL-Rewrite-Modul ist ein natives Codemodul, das in die Anforderungsverarbeitungspipeline in den Phasen mit Vorabanforderungen oder Startanforderungen eingebunden wird und dann den angeforderten URL-Pfad anhand verschiedener Umschreibungsregeln auswertet. Jede Umschreibungsregel analysiert den URL-Pfad und ändert, wenn alle Regelbedingungen erfüllt sind, den ursprünglichen Pfad in einen neuen Pfad. Nachdem alle Regeln ausgewertet wurden, erzeugt das URL-Rewrite-Modul einen endgültigen URL-Pfad, der für die restliche IIS-Pipelineverarbeitung für diese Anforderung verwendet wird. Dies bedeutet, dass die Auswahl des Handlers in der IIS-Pipeline anhand der umgeschriebenen URL erfolgt, die vom URL-Rewrite-Modul erstellt wird.
ASP.NET-Routing
Das ASP.NET-Routing ist ein Mechanismus zur Anforderungsverteilung, mit dem Entwickler und Entwicklerinnen eine bestimmte URL einem Handler zuordnen können, der Anforderungen an diese URL verarbeiten kann. Diese Zuordnung erfolgt durch Registrieren der „Routen“, die definieren, welcher Handler für einen bestimmten URL-Pfad aufgerufen werden soll. Wenn eine Anforderung an einen Webserver erfolgt, sucht ASP.NET-Routing den angeforderten URL-Pfad in der Liste der registrierten Routen. Wenn die Route gefunden wurde, wird der entsprechende Handler für diese Route aufgerufen, um diese Anforderung zu verarbeiten.
Im folgenden Diagramm wird dieser Prozess in der IIS- und ASP.NET-Architektur dargestellt:
ASP.NET-Routing wird als Modul mit verwaltetem Code implementiert, das in der IIS-Anforderungsverarbeitungspipeline in die Phasen der Cacheauflösung (PostResolveRequestCache-Ereignis) und Handlerzuordnung (PostMapRequestHandler-Ereignis) eingebunden wird. ASP.NET-Routing ist so konfiguriert, dass es für alle Anforderungen an die Webanwendung ausgeführt wird.
Während des PostResolveRequestCache-Ereignisses durchsucht das Modul eine Routingtabelle (eine Auflistung von route-Objekten) nach einer Route, die dem angeforderten URL-Pfad entspricht. Wenn eine Übereinstimmung gefunden wurde, ruft das Modul einen Verweis auf den Handler ab, der dieser Route entspricht, und speichert den Verweis als Teil des aktuellen HTTP-Kontexts. Ein Handler kann ein .NET Framework-Objekt sein, das die System.Web.IHttpHandler-Schnittstelle implementiert. Wenn keine Route gefunden wurde, führt das Modul nichts aus, und die URL wird normal weiterverarbeitet (in der Regel durch Abgleich mit einer Datei auf dem Datenträger).
Während des PostMapRequestHandler-Ereignisses überprüft das Modul, ob der HTTP-Kontext Informationen zu einem Handler enthält. Wenn dies der Fall ist, verwendet das ASP.NET-Routing diese Informationen, um die Handlereigenschaft des aktuellen HTTP-Kontexts festzulegen. Dadurch wird sichergestellt, dass IIS während der Handlerausführungsphase den Handler ausführt, der vom Routingmodul ausgewählt wurde. Wenn diese Informationen nicht festgelegt sind, führt das Modul nichts aus, und die URL wird unverändert weitergenutzt, sodass IIS eine Handlerauswahl treffen kann.
Unterschiede zwischen IIS-URL-Umschreibung und ASP.NET-Routing
Gemäß der obigen Erläuterung gibt es die folgenden konzeptionellen Hauptunterschiede zwischen IIS-URL-Umschreibung und ASP.NET-Routing:
- Die URL-Umschreibung dient dazu, URL-Pfade zu bearbeiten, bevor die Anforderung vom Webserver verarbeitet wird. Das URL-Rewrite-Modul weiß nicht, welcher Handler letztendlich die umgeschriebene URL verarbeitet. Darüber hinaus weiß der tatsächliche Anforderungshandler möglicherweise nicht, dass die URL umgeschrieben wurde.
- ASP.NET-Routing dient dazu, eine Anforderung basierend auf dem angeforderten URL-Pfad an einen Handler zu verteilen. Im Gegensatz zur URL-Umschreibung kennt das Routingmodul die Handler und wählt den Handler aus, der eine Antwort für die angeforderte URL generieren soll. Sie können sich ASP.NET-Routing als erweiterten Handlerzuordnungsmechanismus vorstellen.
Zusätzlich zu diesen konzeptionellen Unterschieden gibt es die folgenden funktionalen Unterschiede zwischen IIS-URL-Umschreibung und ASP.NET-Routing:
- Das IIS-URL-Rewrite-Modul kann mit jedem beliebigen Webanwendungstyp verwendet werden, der ASP.NET-, PHP-, ASP- und statische Dateien enthält. ASP.NET-Routing kann nur mit Webanwendungen verwendet werden, die auf .NET Framework basieren.
- Das IIS-URL-Rewrite-Modul funktioniert immer gleich, unabhängig davon, ob der integrierte oder klassische IIS-Pipelinemodus für den Anwendungspool verwendet wird. Beim ASP.NET-Routing empfiehlt es sich, den integrierten Pipelinemodus zu verwenden. ASP.NET-Routing kann im klassischen Modus funktionieren, aber in diesem Fall müssen die Anwendungs-URLs Dateiendungen enthalten, oder die Anwendung muss für die Verwendung der „*“-Handlerzuordnung in IIS konfiguriert werden.
- Das IIS-URL-Rewrite-Modul kann Entscheidungen basierend auf Domänennamen, HTTP-Headern und Servervariablen neu schreiben. Standardmäßig funktioniert ASP.NET-Routing nur mit URL-Pfaden und mit dem HTTP-METHOD-Header.
- Zusätzlich zu Umschreibungen kann das URL-Rewrite-Modul auch HTTP-Umleitungen ausführen, benutzerdefinierte Statuscodes ausgeben und Anforderungen abbrechen. ASP.NET-Routing kann diese Aufgaben nicht ausführen.
- Das URL-Rewrite-Modul ist in seiner aktuellen Version nicht erweiterbar. ASP.NET-Routing ist vollständig erweiterbar und anpassbar.
Welche Option sollten Sie verwenden?
Was bedeutet all diese Informationen für Ihre Technologieauswahl, damit Sie „saubere“ URLs für Ihre Webanwendungen erhalten? In diesem Abschnitt wird erläutert, wie Sie Ihre Auswahl treffen.
Wenn Ihre Webanwendung ohne ASP.NET erstellt wird (die verwendete Technik spielt keine Rolle), verwenden Sie das IIS-URL-Rewrite-Modul. Andernfalls wenden Sie folgende Regeln an:
- Wenn Sie eine neue ASP.NET-Webanwendung entwickeln, die entweder ASP.NET MVC oder ASP.NET Dynamic Data verwendet, wenden Sie ASP.NET-Routing an. Ihre Anwendung profitiert von der nativen Unterstützung für saubere URLs, einschließlich der Generierung sauberer URLs für Links auf Ihren Webseiten. Beachten Sie, dass ASP.NET-Routing noch keine Web-Standardanwendungen unterstützt. Es gibt aber Pläne, dies in der Zukunft zu unterstützen.
- Wenn Sie bereits über eine ältere ASP.NET-Webanwendung verfügen und sie nicht ändern möchten, verwenden Sie das URL-Rewrite-Modul. Mit dem URL-Rewrite-Modul können Sie suchmaschinenfreundliche URLs in ein Format übersetzen, das von Ihrer Anwendung derzeit verwendet wird. Außerdem können Sie Umleitungsregeln erstellen, die zum Umleiten von Suchmaschinencrawlern verwendet werden können, um URLs zu bereinigen.
In der Praxis ist jedoch keine Entweder-Oder-Entscheidung erforderlich. Die Technologien können miteinander kombiniert und ergänzt werden. In den folgenden Abschnitten werden einige Szenarien erläutert, in denen Sie ASP.NET-Routing und IIS-URL-Umschreibung zusammen verwenden können.
Erzwingen kanonischer URLs für Ihre Anwendung.
Sie sollten die Verwendung von http://www.mysite.com/home/about anstelle von http://mysite.com/Home/About erzwingen. Wenn ein Webclient eine URL anfordert, die nicht dem gewünschten Format entspricht, wird der Client an eine kanonische URL umgeleitet. In diesem Szenario können Sie das URL-Rewrite-Modul verwenden, um kanonische URLs zu erzwingen und eine Umleitung durchzuführen. Gleichzeitig können Sie mit ASP.NET-Routing einen Handler auswählen, der den angeforderten URL-Pfad verarbeitet.
Das folgende Beispiel zeigt eine URL-Umschreibungsregel, die Sie für dieses Szenario verwenden können:
<rewrite>
<rules>
<rule name="Enforce canonical hostname" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" negate="true" pattern="^www\.mysite\.com$" />
</conditions>
<action type="Redirect" url="http://www.mysite.com/{R:1}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
Bereitstellen statischer Inhalte von einer anderen Website oder einem anderen Server.
Die Bereitstellung Ihrer Webanwendung erfolgt auf mehreren Servern auf eine Weise, dass sich die dynamischen Webinhalte auf einer Website oder einem Server befinden, während sich alle statischen Inhalte auf einer anderen Website oder einem anderen Server befinden. Sie können das URL-Rewrite-Modul zusammen mit dem IIS-ARR-Modul (Application Request Routing, Routing von Anwendungsanforderungen) verwenden, um alle Anforderungen für statische Dateien an einen anderen Server weiterzuleiten, während alle Anforderungen für dynamische Webseiten vom aktuellen Server verarbeitet werden. Auf diese Weise wird ASP.NET-Routing nur für dynamische Webinhalte verwendet und muss keine URLs für statische Inhalte auswerten.
Das folgende Beispiel zeigt eine URL-Umschreibungsregel, die Sie für dieses Szenario verwenden können:
<rewrite>
<rules>
<rule name="Forward to static file server">
<match url="^.+\.(?:jpg|bmp|gif)$" />
<action type="Rewrite" url="http://static_file_server/{R:0}" />
</rule>
</rules>
</rewrite>
Verwalten statischer Inhalte.
Wenn Ihre statischen Dateien oder Ordner an einen neuen Speicherort verschoben werden, können Sie alte URLs aus Gründen der Abwärtskompatibilität weiterhin unterstützen. Tatsächlich möchten Sie vielleicht nicht, dass Besucher und Besucherinnen Ihrer Website wissen, dass die Dateien oder Ordner verschoben wurden. In diesem Fall können Sie das URL-Rewrite-Modul verwenden, um Pfade für statische Dateien umzuschreiben, während alle URLs zu Ihren dynamischen ASP.NET-Webseiten vom Routingmodul behandelt werden.
Das folgende Beispiel zeigt eine URL-Umschreibungsregel, die Sie für dieses Szenario verwenden können:
<rewrite>
<rules>
<rule name="Rewrite to new folder">
<match url="^Images/(.+)$" />
<action type="Rewrite" url="NewImages/{R:1}" />
</rule>
</rules>
</rewrite>
Anforderungssperren.
Das URL-Rewrite-Modul kann dazu verwendet werden, bestimmte Anforderungen basierend auf verschiedenen Kriterien zu blockieren. Sie können z. B. verhindern, dass einzelne Websitecrawler auf bestimmte URL-Pfade auf Ihrer Website zugreifen. Auf diese Weise gelangen verbotene Anforderungen nicht einmal zum ASP.NET-Router, wodurch die Last auf Ihrem Webserver reduziert wird.
Das folgende Beispiel zeigt eine URL-Umschreibungsregel, mit der Sie unerwünschte Websitecrawler blockieren können. Beachten Sie, dass die Anforderungen für einen bestimmten URL-Pfad basierend auf dem HTTP-Header des Benutzer-Agents oder basierend auf der IP-Adresse des Clients blockiert werden:
<rewrite>
<rules>
<rule name="Block SomeRobot" stopProcessing="true">
<match url="^folder1/folder2" />
<conditions logicalGrouping="MatchAny">
<add input="{USER_AGENT}" pattern="SomeRobot" />
<add input="{REMOTE_ADDR}" pattern="201\.45\.33\.[0-5]" />
</conditions>
<action type="AbortRequest" />
</rule>
</rules>
</rewrite>
Zukünftige Ausrichtung
Obwohl IIS-URL-Umschreibung und ASP.NET-Routing gewisse funktionale Überschneidungen aufweisen, gibt es Szenarien, die für jede dieser Technologien einzigartig sind. Aus diesem Grund werden diese beiden Technologien weiterhin existieren und als unabhängige Komponenten in IIS entwickelt – potenziell mit einer engeren Integration. Beispielsweise kann ASP.NET-Routing einige der umfangreichen Tools nutzen, die vom URL-Rewrite-Modul bereitgestellt werden. Das URL-Rewrite-Modul wiederum kann besser in ASP.NET integriert werden, um Erweiterbarkeit zum Anpassen der URL-Umschreibungslogik bereitzustellen.
Zusammenfassung
Sie können in Szenarien, in denen Sie URLs für Ihre Webanwendung bearbeiten möchten, entweder die IIS-URL-Umschreibung oder ASP.NET-Routing verwenden. ASP.NET-Routing ist eine Lösung, die für ASP.NET optimiert und daher möglicherweise besser für die Webentwicklung geeignet ist, bei der ASP.NET-Anwendungen von Grund auf und mit einer klaren URL-Struktur entworfen werden sollen. Die IIS-URL-Umschreibung ist ein allgemeiner Mechanismus für die URL-Bearbeitung, der eine Vielzahl von Szenarien abdeckt. Insbesondere kann sie für die Webentwicklung und Webserver-/Websiteverwaltung verwendet werden, um saubere URLs für vorhandene Webanwendungen zu erhalten, ohne den Anwendungscode zu ändern.
Verwandte Dokumente
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für