Startseite>Tutorial zur Netzwerkprogrammierung>ASP.NET-Tutorial

URL Rewrite(2): Verwendung von Komponenten für URL Rewrite

Autor：Eve Cole Aktualisierungszeit：2009-06-29 23:46:44
Das Prinzip der URL-Rewrite-Komponente auf asp.net -Ebene ist sehr einfach. Tatsächlich lauscht sie lediglich auf das BeginRequest-Ereignis und bestimmt die Ziel-URL entsprechend der Konfiguration. Bei den Projekten, an denen ich zuvor beteiligt war, habe ich festgestellt, dass URLRewriter sehr häufig als URL-Rewrite-Komponente verwendet wird. Ich denke, das liegt möglicherweise daran, dass es sich um etwas handelt, das von Microsoft bereitgestellt wird.
Wenn Sie URLRewriter verwenden möchten, besteht der erste natürliche Schritt darin, ein HttpModule in web.config zu konfigurieren:

<httpModules>
< hinzufügen
name = „ ModuleRewriter “
type = " URLRewriter.ModuleRewriter, URLRewriter " />
</httpModules>

Dann ist es Zeit für die Konfiguration (Hinweis: Es wird dringend empfohlen, das configPath-Attribut zu verwenden, um die Konfiguration zur einfacheren Verwaltung in zusätzliche Dateien zu extrahieren):
<configSections>
< Abschnitt
name = " RewriterConfig "
type = " URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter " />
</configSections>
<RewriterConfig>

<Regeln>

<RewriterRule>

< LookFor > ~/tag/([w]+)/ </ LookFor >

< SendTo > ~/Tags.aspx?Tag=$1 </ SendTo >

</RewriterRule>

</ Regeln >
</RewriterConfig>

Reguläre Ausdrücke sind eine erstaunliche Sache, sie können übereinstimmen und erfassen. Im obigen Beispiel verschieben wir „/tag/xxx“, das die LookFor-Bedingungen erfüllt, auf die Seite Tags.aspx und verwenden xxx als Wert des Tag QueryString-Elements, damit wir HttpContext.Request.QueryString im Code übergeben können . ["Tag"], um den Wert zu erhalten.
Die Funktionalität von URLRewriter reicht für die meisten Anwendungen aus, aber sie hat mir schon immer nicht gefallen. Aber wenn Sie mich fragen müssen, warum ich es nicht mag, kann ich Ihnen nicht das hässliche Yinmao nennen. Vielleicht ist es nur ein Problem mit dieser Konfigurationsmethode. Bei Verwendung von URL Rewriter ist der Konfigurationsabschnitt oft sehr lang. Jedes Konfigurationselement erfordert insgesamt 4 Codezeilen von <RewriterRule> bis </RewriterRule>. Ein kleines Projekt kann leicht Hunderte von Konfigurationszeilen umfassen. „Das ist zu XML“, dachte ich, warum nicht XML-Attribut verwenden? Dadurch wird jedes Konfigurationselement auf eine Zeile reduziert – aber das ist ein Exkurs.
Wenn ich also derzeit URL Rewrite durchführen möchte, verwende ich oft die Open-Source-Komponente UrlRewriter.NET von Intelligencia . Obwohl dieser Name dem vorherigen sehr ähnlich ist, ist seine Funktionalität dem ersteren weit überlegen. Diese Komponente kommt dem verwendeten URLRewriter relativ nahe (tatsächlich scheinen alle URL-Rewrite-Komponenten ähnlich zu sein. Alles, was wir tun müssen, ist Folgendes zu konfigurieren).

<configSections>
< Abschnitt
name = „ Umschreiber “

 type = " Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler ,

Intelligencia.UrlRewriter " />
</configSections>


<rewriter>

< umschreiben
url = " ^/Benutzer/(d+)$ "
to = " ~/User.aspx?id=$1 "
Verarbeitung = „ Stopp “ />

< umschreiben
url = " ^/User/(w+)$ "
to = " ~/User.aspx?name=$1 "
Verarbeitung = „ Stopp “ />
</rewriter>


< system.web >

<httpModules>

< hinzufügen
name = " UrlRewriter "

 type = " Intelligencia.UrlRewriter.RewriterHttpModule,

Intelligencia.UrlRewriter " />

</httpModules>
< /system.web >
Schauen wir uns hauptsächlich das Konfigurationselement <rewriter /> der Rewrite-Regeln an. Im Gegensatz zu URLRewriter verwendet UrlRewriter.NET meine Lieblingsmethode mit einem Knoten pro Regel, wodurch die Umschreiberegeln des gesamten Projekts viel einfacher werden. Aber was bedeutet processing="stop"? Hier geht es um die Art und Weise, wie UrlRewriter.NET mit Umschreibregeln umgeht. Wenn UrlRewriter.NET eine passende Umschreiberegel findet, stoppt es hier nicht, sondern sucht weiter nach anderen Übereinstimmungen. Die letzte Umschreiberegel, die mit der aktuellen Anforderung übereinstimmen kann, wird schließlich wirksam. Wenn UrlRewriter.NET nach dem Finden einer Übereinstimmung wirksam werden soll, müssen wir das Verarbeitungsattribut auf Stopp setzen. Wenn beispielsweise in der obigen Konfiguration auf „/Benutzer/“ eine Zahl folgt, wird die Benutzer-ID für die Suche verwendet, andernfalls wird der aktuell angegebene Benutzername berücksichtigt.
Wenn UrlRewriter.NET nur einfacher zu konfigurieren ist, hat es keinen Vorteil gegenüber URLRewriter. Aber die Fähigkeiten von UrlRewriter.NET gehen weit darüber hinaus. Was wir gerade verwendet haben, ist eigentlich nur eine der Aktionen, die es bietet. Darüber hinaus bietet es auch viele Aktionen.

  • wenn
  • es sei denn
  • , umschreiben,
  • umleiten,
  • setstatus,
  • verboten
  • , nicht erlaubt,
  • nicht gefunden,
  • nicht
  • implementiert
  • , addheader,
  • setcookie,
  • setproperty
. Die Aktion allein reicht nicht aus und kann auch Bedingung, Urlform, Standarddokument, Parser, Fehlerhandler, Logger und andere Funktionen bereitstellen Ausdruck zur „Darstellung“ komplexer Logik. Das ist keine Konfiguration, es ist einfach Programmierung! Das ist richtig, UrlRewriter.NET kann verwendet werden, um eine Anforderungs-Antwort-Logik durch Konfiguration auszudrücken, was uns zweifellos großen Komfort bringt. Es ist mir unmöglich, hier alle Aspekte von UrlRewriter.NET im Detail zu erklären. Interessierte Freunde können sich die auf der offiziellen Website bereitgestellte Referenz genauer ansehen. „Wenn Sie solche Komponenten haben, was will man mehr?“ Ich möchte hier jedoch noch eine andere Komponente empfehlen. Denn in einigen Sonderfällen kann UrlRewriter.NET unsere Anforderungen nicht erfüllen. Äh? Kann es nicht von alleine expandieren? Das ist richtig, aber – lassen Sie uns das zunächst klären, und ich werde dieses Problem im letzten Artikel dieser Serie erläutern. UrlRewriter.NET bietet URL Rewriter auf ASP.NET-Ebene. Wenn Sie URL Rewrite auf IIS-Ebene durchführen möchten, müssen Sie andere Methoden verwenden. ISAPI Rewrite ist eine bekannte Komponente für URL Rewrite auf IIS-Ebene. Leider ist dies eine kommerzielle Komponente und erfordert den Kauf in US-Dollar. Daher empfehle ich hier ein weiteres Open-Source-Produkt: IIRF (Isapi Rewrite Filter von Ionic) .
Da das URL-Rewrite auf IIS-Ebene durchgeführt wird, unterscheidet sich die Konfigurationsmethode von IIRF von der von UrlRewriter.NET. Wenn Sie IIRF verwenden möchten, müssen Sie IsapiRewrite4.dll zur ISAPI-Filterliste der Website hinzufügen:
IIRF wird über die INI-Datei konfiguriert und IsapiRewrite4.dll kann im selben Verzeichnis abgelegt werden:
RewriteRule ^/User/(d+)$ /User.aspx?id=$1 [I, L]
RewriteRule ^/User/(w+)$ /User.aspx?name=$1 [I, L]
Die Umschreiberegel von IIRF lautet „RewriteRule <URL-Muster> <Ziel> [<Modifikatoren>]“. Es gibt keine Begrenzung für die Anzahl der Leerzeichen zwischen den einzelnen Teilen, es muss jedoch ein Leerzeichen sein, keine anderen Leerzeichen wie Tab . Es erübrigt sich zu erwähnen, dass „URL-Muster“ und „Ziel“ der Schlüssel im Modifikator liegt. Es gibt viele Modifikatoren für IIRF. Hier werde ich nur die beiden oben verwendeten vorstellen. „I“ bedeutet, dass die Übereinstimmung unabhängig von der Groß- und Kleinschreibung ist. Die Funktion „processing="stop" in UrlRewriter.NET wird sofort wirksam, wenn die Übereinstimmung gefunden wird, und die Suche wird nicht fortgesetzt.
Obwohl IIRF eine Open-Source-Komponente ist, sind seine Funktionen immer noch relativ leistungsstark. Insbesondere nach der Kombination von RewriteCond (Rewrite Condition) können komplexere Umschreiberegeln implementiert werden. Die folgende Konfiguration schreibt beispielsweise die Stammverzeichnisanforderung, die das Wort Googlebot im UserAgent enthält, in eine bestimmte Ressource um:
RewriteCond %{HTTP_USER_AGENT} ^Googlebot.*
RewriteRule ^/ $/Googlebot.html [L]
Schauen wir uns abschließend den Unterschied zwischen den beiden Komponenten Rewrite an. Der größte Unterschied besteht offensichtlich darin, dass es sich um Umschreibungen auf unterschiedlichen Ebenen handelt. Die beiden folgenden schematischen Diagramme beschreiben, wie sie in den beiden Fällen das Ergebnis „404 Ressource nicht gefunden“ ändern „/Benutzer/name=jeffz“.
Das erste ist URL Rewrite durch UrlRewriter.NET auf ASP.NET-Ebene:
Als nächstes folgt die URL-Umschreibung des IIRF auf IIS-Ebene:

Ich glaube, dass wir mit diesen beiden Komponenten nichts anderes mehr brauchen, um URL Rewrite zu implementieren.