URL Rewrite（1）：IIS与ASP.NET

Um die später in diesem Artikel behandelten Themen vollständig zu verstehen, müssen wir kurz den Kommunikationsprozess zwischen IIS und ASP.NET verstehen. Was ich hier erkläre, ist der IIS 6-Server. Was IIS 5 und IIS 7 betrifft, so kann man sagen, dass Ersteres eliminiert wurde, während der „klassische Modus“ des Letzteren genau derselbe wie IIS 6 ist und der neue „Pipeline-Modus“ tatsächlich über einige Konzepte in ASP spricht. NET und IIS. Tiefe Integration. Ich glaube, wenn Sie IIS 6 und ASP.NET verstehen, werden Sie im integrierten Modus von IIS 7 keine Probleme haben.

Schauen wir uns zunächst ein einfaches schematisches Diagramm an, das mehrere Hauptschritte im gesamten IIS-Prozess vom Empfang der Anfrage bis zur Rückgabe der Antwort zeigt:

1. IIS empfängt die Anfrage.
2. Der Selektor wählt eine ISAPI zur Bearbeitung der Anfrage basierend auf den Eigenschaften der URL und der Konfiguration in IIS aus – jetzt ist es selbstverständlich, ASP.NET ISAPI zu wählen.
3. Die ASP.NET-Ausführungs-Engine empfängt die Anfrage und initialisiert die Daten (z. B. das Erstellen verschiedener Objekte).
4. Beginnen Sie mit dem Auslösen verschiedener Pipeline-Ereignisse, beginnend natürlich mit BeginRequest.
5. Nach mehreren Pipeline-Ereignissen wählt ASP.NET entsprechend der Konfiguration einen geeigneten Handler oder eine HandlerFactory für die aktuelle Anforderung aus (mit Ausnahme besonderer Umstände, z. B. der direkten Ausgabe der Ergebnisse und dem Beenden der Anforderung im vorherigen Ereignis).
6. Nach der Verarbeitung durch den Handler durchläuft es mehrere Pipeline-Ereignisse und endet mit EndRequest.
7. Ausgabeantwort.

Wenn Sie URL Rewrite in einer ASP.NET-Anwendung durchführen möchten, rufen Sie normalerweise die RewritePath-Methode von HttpContext im BeginRequest-Ereignis auf, um die Anforderung an eine Ziel-URL neu zu positionieren. Wir können beispielsweise die Methode Application_BeginRequest in Global.asax überschreiben, um Folgendes zu erreichen:

Der Grund, warum Rewrite in BeginRequest durchgeführt wird, liegt darin, dass dieses Ereignis das am frühesten ausgelöste Ereignis unter allen Pipeline-Ereignissen ist. Nach der Neupositionierung zu diesem Zeitpunkt haben sich auch einige Eigenschaften im aktuellen HttpContext entsprechend geändert (z. B. HttpContext.Request.Path). Auf diese Weise wird die Handlerlogik der folgenden Pipeline-Ereignisse beeinflusst. Wenn beispielsweise Berechtigungen basierend auf einem Verzeichnis ermittelt werden müssen, wird der „gefundene“ Pfad anstelle der von ASP.NET empfangenen Anforderung verwendet. Die „wichtigste“ Änderung ist natürlich die Wahl des Handlers. Im obigen Beispiel verschieben wir die Anfrage beispielsweise in die Datei „CustomerList.aspx“, sodass die ASP.NET-Engine die Datei „System.Web.UI“ auswählt entsprechend *.aspx. Die PageHandlerFactory-Klasse verarbeitet Anfragen.

öffentliche Klasse Global : System.Web HttpApplication
{
    protected void Application_BeginRequest( Objektsender , EventArgs e)
    {
        HttpContext context = HttpContext .Current;
 
        if (context.Request.Path.Equals( "/Customers" ,
            StringComparison .InvariantCultureIgnoreCase))
        {
            context.RewritePath( "~/CustomerList.aspx" );
        }
    }
}

Abschließend müssen noch zwei Konzepte unterschieden werden, nämlich „ASP.NET Pipeline“ und „Web Forms“. Beides sind wichtige Modelle in ASP.NET, aber die Unterschiede sind immer noch sehr groß:

• ASP.NET-Pipeline: Wie jede Anfrage, die von einer ASP.NET-Anwendung empfangen wird, wird sie über diese „Pipeline“ verarbeitet. Dies ist ein Modell auf ASP.NET-Ebene.
• Webformulare: Während der Ausführung der ASP.NET-Pipeline besteht einer der Schritte darin, einen geeigneten Handler (oder HandlerFactory) zur Bearbeitung der Anfrage auszuwählen. Wenn es sich um eine ASPX-Seite handelt, wählt ASP.NET die Klasse System.Web.UI.PageHandlerFactory aus, in der das WebForms-Modell schließlich gebildet wird.

Tatsächlich ist das Wort „Form“ im obigen Satz möglicherweise nicht korrekt. Denn Web Forms sollte wahrscheinlich eine Ausführungs-Engine und ein Modell sein, die unabhängig verwendet werden können, und System.Web.UI.PageHandlerFactory verwendet nur dieses Modell. Wenn wir ASP.NET-Anwendungen schreiben, können wir dieses Modell je nach Bedarf an anderen Stellen verwenden. Im Artikel „ Technik: Benutzersteuerung zur HTML-Generierung verwenden “ verwenden wir beispielsweise ascx als Vorlage in einem generischen Handler zum Generieren von Inhalten.