In früheren Artikeln haben wir über mehrere Hauptaspekte von URL Rewrite gesprochen. Im letzten Artikel dieser Serie werden wir einige Details und Merkmale verschiedener Ebenen des URL-Rewrite besprechen.
Theoretisch weist in C oder C++ geschriebenes URL-Rewrite auf IIS-Ebene eine höhere Leistung auf als in verwaltetem Code geschriebenes URL-Rewrite auf ASP.NET-Ebene. Ich denke jedoch, dass der Unterschied in diesem Bereich in den meisten Fällen vernachlässigbar ist und es fast unmöglich ist, dass diese Leistung zu einem Leistungsengpass wird. Daher wird der gewählte Grad der URL-Umschreibung im Allgemeinen nicht durch die Leistungsanforderungen Ihrer Anwendung bestimmt. Welche Stufe des URL-Rewrite sollte also verwendet werden? Worauf sollten wir achten, nachdem wir verschiedene Ebenen des URL-Rewrite verwendet haben? Ich bin hier, um über meine persönlichen Ansichten zu sprechen.
Obwohl die aktuelle URL Rewrite-Komponente hinsichtlich der Funktionalität die meisten Anwendungen erfüllen kann, benötigen wir an einem bestimmten Punkt noch einige spezielle Funktionen. Beispielsweise ist das URL-Rewrite auf Basis des Domänennamens mit der aktuellen URL-Rewrite-Komponente nicht einfach zu erreichen. Das kommerzielle ISAPI Rewrite kann dies derzeit unterstützen. Leider verfügen die Open-Source-Versionen UrlRewriter.NET und IIRF diesbezüglich nicht über ausreichende Funktionen. Sie werden alle basierend auf dem Pfad der Anforderung relativ zur Site abgeglichen, und der angeforderte Domänenname kann nicht als Übereinstimmungsbedingung verwendet werden. Dies erfordert eine Erweiterung der URL-Rewrite-Komponente. Für die meisten .NET-Entwickler ist verwalteter Code natürlich die erste Wahl für die Entwicklung. Zu diesem Zeitpunkt kann es erforderlich sein, die Umschreibungskomponente URL Rewrite auf ASP.NET-Ebene auszuwählen. Allerdings sind im Internet viele Erweiterungsbeispiele zu finden, sei es UrlRewriter.NET auf ASP.NET-Ebene oder IIRF auf IIS-Ebene.
Wenn wir die oben genannten Funktionen erreichen möchten, können wir dies jedoch auch in zwei Schritten tun. Zuerst verwenden wir IIRF für URL-Rewrite auf IIS-Ebene und dann weiteres URL-Rewrite auf ASP.NET-Ebene. Wenn wir nun beispielsweise „ http://jeffz.domain.com/articles “ in „/ArticleList.aspx?owner=jeffz“ umschreiben möchten, können wir IIRF zunächst das erste URL-Rewrite durchführen lassen, mit dem Zweck des Umschreibens „/articles“ wird in „/ArticleList.aspx“ umgeschrieben.
RewriteRule ^/Articles$ /ArticleList.aspx [I, L, U]
Auf diese Weise erhält die ASP.NET-Engine direkt eine Anfrage für /ArticleList.aspx. Dann können wir in ASP.NET das zweite URL-Rewrite durchführen (der Einfachheit halber schreibe ich es immer noch in Global.asax und es wird empfohlen, zusätzliches HttpModule im Projekt zu verwenden).
protected void Application_BeginRequest( Objektsender , EventArgs e)
{
HttpContext context = HttpContext .Current;
string host = context.Request.Url.Host;
stringowner = host.Substring(0, host.IndexOf( '.' ));
context.RewritePath(context.Request.RawUrl + "?owner=" +owner);
}
Nach zwei URL-Umschreibungen wurde der gewünschte Effekt erzielt (in tatsächlichen Projekten kann der obige Code nicht direkt verwendet werden, da beurteilt werden muss, ob eine Abfragezeichenfolge usw. vorhanden ist).
Darüber hinaus kann URL Rewrite auf ASP.NET-Ebene nur in ASP.NET funktionieren (offensichtlich). Wenn Sie möchten, dass URL Rewrite andere Servertechnologien wie PHP, RoR usw. unterstützt, können Sie nur URL Rewrite auf IIS-Ebene verwenden (oder eine andere URL-Rewrite-Funktion, die von der Servertechnologie bereitgestellt wird).
Einige Sonderzeichen dürfen in URLs nicht vorkommen, oder sobald sie in URLs erscheinen, ändert sich die Bedeutung der Anfrage. Beispielsweise müssen wir auf der Suchseite eine URL-Umschreibung durchführen, „/Search/xxx“ in „/Search.aspx?xxx“ umschreiben und dann die vom Benutzer bereitgestellten Schlüsselwörter basierend auf der Zeichenfolge nach dem Fragezeichen abrufen. Wenn Sie UrlRewriter.NET verwenden, verwenden wir die folgende Konfiguration:
< rewriter >
< umschreiben url = " ^/Search/(.+)$ " to = " ~/Search.aspx?$1 " Verarbeitung = „ Stopp “ />
</ rewriter >
Unter normalen Umständen funktioniert dieses URL-Rewrite normal. Wenn der Benutzer jedoch „%“ als Schlüsselwort verwendet, ist die Situation anders, da wir die folgende Fehlermeldung auf der Seite erhalten:
Dies liegt daran, dass „%“ in der URL nicht zulässig ist. Sie können auf verschiedene Websites gehen und versuchen, einige Pfade wie „ABC%25DEF“ („auf %25“ folgt „%“) anzufordern, und die meisten von ihnen werden den Fehler „400 Bad Request“ finden. Es ist jedoch zulässig, „%“ in die Abfragezeichenfolge einzufügen – ja, haben wir das Schlüsselwort nicht in die Abfragezeichenfolge umgeschrieben? Warum funktioniert es immer noch nicht? Dies wird auch durch die Art und Weise bestimmt, wie ASP.NET ausgeführt wird.
Die Feststellung einer fehlerhaften Anfrage erfolgt in Schritt 3 der obigen Abbildung, also noch während der Initialisierung. Unser URL-Rewrite erfolgt nur im BeginRequest-Ereignis in Schritt 4. Wenn die Anfrage illegale Zeichen enthält, haben wir überhaupt keine Möglichkeit, die URL-Umschreibung durchzuführen.
Wie gehen wir also mit diesem Problem um? Unter normalen Umständen stellt es kein großes Problem dar, wenn wir % auf dem Client entfernen (einige Websites tun dies), aber was ist, wenn wir es behalten müssen? Verwenden Sie dann die Abfragezeichenfolge, um Parameter zu übergeben, oder wir können auch URL Rewrite auf IIS-Ebene verwenden. Nehmen wir immer noch IIRF als Beispiel:
RewriteRule ^/Search/(.+)$ /Search.aspx?$1 [I, L, U]
Wenn die Anfrage an IIS gesendet wird (Schritt 1) und nachdem ausgewählt wurde, welche ISAPI übergeben werden soll zur Ausführung übergeben (Schritt 2) Die URL-Umschreibung wurde bereits durchgeführt. Nach dem URL-Rewrite wurde das „%“ in der Adresse in die Abfragezeichenfolge übertragen und ist bei der Übergabe an ASP.NET zur Verarbeitung natürlich legal.
Lassen Sie uns abschließend die Konfiguration der Fehlerseite besprechen. Im Allgemeinen konfigurieren wir beispielsweise eine 404-Fehlerseite für die Anwendung, sodass wir dem Benutzer, wenn er auf eine nicht vorhandene Ressource zugreift, eine bestimmte Seite anstelle der Standardfehleraufforderung anzeigen können. Zu diesem Zeitpunkt müssen jedoch verschiedene Ebenen des URL-Rewrites mit unterschiedlichen Methoden konfiguriert werden.
Wenn wir URL Rewrite auf ASP.NET-Ebene verwenden, haben wir im Allgemeinen die Wildcard-Zuordnung in IIS eingerichtet, sodass jede Anfrage (einschließlich HTML, JPG usw.) von ASP.NET verarbeitet wird. Wenn eine nicht vorhandene Ressource angefordert wird, wird von ASP.NET ein 404-Fehler ausgegeben. Daher sollte die 404-Fehlerseite in web.config konfiguriert werden:
< customErrors Modus = „ Ein “ defaultRedirect = " GenericErrorPage.htm " >
< Fehler statusCode = " 404 " weitergeleitet = " FileNotFound.htm " />
</ customErrors >
Wenn wir URL Rewrite auf IIS-Ebene verwenden, konfigurieren wir keine Wildcard-Zuordnung. Mit anderen Worten: Die ASP.NET-Engine beginnt erst zu arbeiten, wenn die Adresse nach dem Umschreiben aspx ist (oder andere Dinge, die von ASP.NET ISAPI hätten verarbeitet werden sollen). Wenn der Benutzer eine Ressource anfordert, die nicht vorhanden ist, wird von IIS ein 404-Fehler ausgegeben. Zu diesem Zeitpunkt sollte die 404-Fehlerseite in IIS konfiguriert werden:
Bisher wurde das Thema URL Rewrite besprochen. In der tatsächlichen Entwicklung werden Sie sicherlich auf verschiedene Situationen stoßen, aber solange Sie den Schlüssel zur URL-Rewrite-Methode verstehen und entsprechend der Art und Weise denken, wie das Programm ausgeführt wird, werden Sie meiner Meinung nach im Allgemeinen nicht auf schwierige Probleme stoßen.