Übersicht über HTTP-Handler und HTTP-Module

Aktualisiert: November 2007

Ein ASP.NET-HTTP-Handler ist der Prozess (oder "Endpunkt"), der als Antwort auf eine Anforderung an eine ASP.NET-Webanwendung ausgeführt wird. Der gebräuchlichste Handler ist ein ASP.NET-Seitenhandler, der ASPX-Dateien verarbeitet. Wenn Benutzer eine ASPX-Datei anfordern, wird die Anforderung von der Seite mithilfe des Seitenhandlers verarbeitet. Sie können eigene HTTP-Handler erstellen, die die benutzerdefinierte Ausgabe für den Browser rendern.

Ein HTTP-Modul ist eine Assembly, die bei jeder Anforderung an die Anwendung aufgerufen wird. HTTP-Module werden als Teil der ASP.NET-Anforderungspipeline aufgerufen und haben während der gesamten Anforderung Zugriff auf Lebenszyklusereignisse. Mithilfe von HTTP-Modulen haben Sie daher die Möglichkeit, eingehende und ausgehende Anforderungen zu überprüfen und basierend auf der Anforderung eine Aktion auszuführen.

Dieses Thema enthält folgende Abschnitte:

  • Szenarien

  • Features von HTTP-Handlern und HTTP-Modulen

  • Hintergrund

  • Codebeispiele

  • Klassenreferenz

Szenarien

Typische Verwendungen für benutzerdefinierte HTTP-Handler sind z. B.:

  • RSS-Newsfeeds: Um einen RSS-Newsfeed für eine Website anzulegen, können Sie einen Handler erstellen, der RSS-formatierte XML-Daten ausgibt. Sie können dann einen Dateinamen anbinden, z. B. die RSS-Erweiterung an den benutzerdefinierten Handler. Wenn ein Benutzer eine Anforderung an die Site sendet, die mit RSS endet, ruft ASP.NET zum Verarbeiten der Anforderung den Handler auf.

  • Bildserver: Für eine Webanwendung zur Bereitstellung von Bildern in verschiedenen Größen können Sie einen benutzerdefinierten Handler schreiben, der die Größe der Bilder anpasst und diese dann als Antwort des Handlers an den Benutzer sendet.

Typische Verwendungen für HTTP-Module sind z. B.:

  • Sicherheit: Da sich eingehende Anforderungen überprüfen lassen, kann das HTTP-Modul eine benutzerdefinierte Authentifizierung oder andere Sicherheitsüberprüfungen durchführen, bevor die angeforderte Seite, der angeforderte XML-Webdienst oder der angeforderte Handler aufgerufen wird. Wenn Internetinformationsdienste (IIS) 7.0 im integrierten Modus ausgeführt wird, können Sie die Formularauthentifizierung auf alle Inhaltstypen der Anwendung ausdehnen.

  • Statistik und Protokollierung: Da HTTP-Module bei jeder Anforderung aufgerufen werden, können Sie Anforderungsstatistiken und Protokollinformationen in einem zentralen Modul sammeln, anstatt in einzelnen Seiten.

  • Benutzerdefinierte Kopf- und Fußzeilen: Aufgrund der Möglichkeit, die ausgehende Antwort zu ändern, können Sie Inhalte, z. B. benutzerdefinierte Headerinformationen, in jede Seite bzw. in jeden XML-Webdienst einfügen.

Zurück nach oben

Features

Features von HTTP-Handlern und -Modulen sind z. B.:

  • Die Schnittstellen IHttpHandler und IHttpModule sind der Ausgangspunkt für die Entwicklung von Handlern und Modulen.

  • Die IHttpAsyncHandler-Schnittstelle ist der Ausgangspunkt zum Entwickeln von asynchronen Handlern.

  • Sie können benutzerdefinierten Quellcode für Handler und Module in den Ordner App_Code einer Anwendung einfügen, oder Sie können den Quellcode kompilieren und in den Ordner Bin einer Anwendung einfügen.

  • Handler und Module, die für die Verwendung in IIS 6.0 entwickelt wurden, können in IIS 7.0 unverändert bzw. mit nur geringen Änderungen verwendet werden. Weitere Informationen finden Sie unter Verschieben einer ASP.NET-Anwendung von IIS 6.0 nach IIS 7.0.

  • Module können eine Vielzahl von Anforderungspipeline-Benachrichtigungen abonnieren. Außerdem können Module Benachrichtigungen über Ereignisse des HttpApplication-Objekts empfangen.

  • In IIS 7.0 ist die Anforderungspipeline in die Webserver-Anforderungspipeline integriert. HTTP-Module können für beliebige Anforderungen an den Webserver verwendet werden, nicht nur für ASP.NET-Anforderungen.

Zurück nach oben

Hintergrund

HTTP-Handler

Ein ASP.NET-HTTP-Handler ist der Prozess, der als Antwort auf eine Anforderung an eine ASP.NET-Webanwendung ausgeführt wird. Der gebräuchlichste Handler ist ein ASP.NET-Seitenhandler, der ASPX-Dateien verarbeitet. Wenn Benutzer eine ASPX-Datei anfordern, wird die Anforderung mithilfe des Seitenhandlers verarbeitet.

Der ASP.NET-Seitenhandler ist nur einer von vielen Handlertypen. ASP.NET bietet eine Reihe weiterer integrierter Handler, z. B. den Webdiensthandler für ASMX-Dateien.

Integrierte HTTP-Handler in ASP.NET

In ASP.NET werden HTTP-Anforderungen und HTTP-Handler anhand von Dateinamenerweiterungen einander zugeordnet. Jeder HTTP-Handler ermöglicht die Verarbeitung einzelner HTTP-URLs oder von Gruppen von URL-Erweiterungen innerhalb einer Anwendung. ASP.NET bietet mehrere integrierte HTTP-Handler, wie in der folgenden Tabelle aufgeführt.

Handler

Beschreibung

ASP.NET-Seitenhandler (*.aspx)

Der standardmäßige HTTP-Handler für alle ASP.NET-Seiten.

Webdiensthandler (*.asmx)

Der Standard-HTTP-Handler für Webdienstseiten, die in ASP.NET als ASMX-Dateien erstellt werden.

Generischer Webhandler (*.ashx)

Der standardmäßige HTTP-Handler für alle Webhandler, die keine Benutzeroberfläche aufweisen und keine @ WebHandler-Direktive enthalten.

Ablaufverfolgungshandler (trace.axd)

Ein Handler, der Ablaufverfolgungsinformationen der aktuellen Seite anzeigt. Ausführliche Informationen finden Sie unter Gewusst wie: Anzeigen von ASP.NET-Ablaufverfolgungsinformationen mit dem Ablaufverfolgungs-Viewer.

Erstellen eines benutzerdefinierten HTTP-Handlers

Um einen benutzerdefinierten HTTP-Handler zu erstellen, erstellen Sie eine Klasse, die zum Erstellen eines synchronen Handlers die IHttpHandler-Schnittstelle implementiert. Alternativ dazu können Sie auch IHttpAsyncHandler implementieren, um einen asynchronen Handler zu erstellen. Für beide Handlerschnittstellen müssen Sie die IsReusable-Eigenschaft und die ProcessRequest-Methode implementieren. Die IsReusable-Eigenschaft gibt an, ob das IHttpHandlerFactory-Objekt (das Objekt, das den entsprechenden Handler aufruft) den Handler in einen Pool einfügen und wiederverwenden kann, um die Leistung zu erhöhen. Wenn der Handler nicht in einen Pool eingefügt werden kann, muss die Factory jedes Mal eine neue Instanz des Handlers erstellen, wenn dieser benötigt wird.

Die ProcessRequest-Methode ist dafür verantwortlich, die einzelnen HTTP-Anforderungen zu verarbeiten. In dieser Methode schreiben Sie den Code, der die Ausgabe für den Handler erzeugt.

HTTP-Handler verfügen über Zugriff auf den Anwendungskontext. Dies gilt auch für die Identität des anfordernden Benutzers (falls bekannt), den Anwendungszustand und die Sitzungsinformationen. Beim Anfordern eines HTTP-Handlers ruft ASP.NET die ProcessRequest-Methode des entsprechenden Handlers auf. Der Code, den Sie in der ProcessRequest-Methode des Handlers schreiben, erstellt eine Antwort, die zurück an den anfordernden Browser gesendet wird.

Zuordnen einer Dateinamenerweiterung

Wenn Sie eine Klassendatei als HTTP-Handler erstellen, kann der Handler auf alle Dateinamenerweiterungen antworten, die in IIS und ASP.NET noch nicht zugeordnet sind. Wenn Sie z. B. einen HTTP-Handler zum Generieren eines RSS-Newsfeeds erstellen, können Sie den Handler der Dateinamenerweiterung RSS zuordnen. Damit ASP.NET für die benutzerdefinierte Dateinamenerweiterung den richtigen Handler verwendet, müssen Sie die Erweiterung ASP.NET in IIS zuordnen. In der Anwendung müssen Sie die Erweiterung dann dem benutzerdefinierten Handler zuordnen.

Standardmäßig ordnet ASP.NET die Dateinamenerweiterung ASHX einem HTTP-Handler zu. Wenn Sie die @ WebHandler-Direktive einer Klassendatei zuordnen, ordnet ASP.NET die Dateinamenerweiterung ASHX automatisch dem standardmäßigen HTTP-Handler zu. Dies ist vergleichbar damit, wenn ASP.NET die Dateinamenerweiterung ASPX dem ASP.NET-Seitenhandler bei Verwendung der @ Page-Direktive zuordnet. Dementsprechend wird, wenn Sie eine HTTP-Handlerklasse mit der Dateinamenerweiterung ASHX erstellen, der Handler automatisch bei IIS und ASP.NET registriert.

Wenn Sie eine benutzerdefinierte Dateinamenerweiterung für einen Handler erstellen möchten, müssen Sie die Erweiterung explizit bei IIS und ASP.NET registrieren. Wenn Sie nicht die Dateinamenerweiterung ASHX verwenden, haben Sie den Vorteil, dass Sie den Handler dann für andere Erweiterungszuordnungen wiederverwenden können. Zum Beispiel kann der benutzerdefinierte Handler in einer Anwendung auf Anforderungen reagieren, die auf RSS enden. In einer anderen Anwendung kann er auf Anforderungen reagieren, die auf FEED enden. Des Weiteren kann der Handler in der gleichen Anwendung beiden Dateinamenerweiterungen zugeordnet werden und je nach Erweiterung unterschiedliche Antworten generieren.

Die Registrierung der benutzerdefinierten Dateinamenerweiterung eines Handlers ist für IIS 7.0 und ältere IIS-Versionen verschieden. Weitere Informationen finden Sie unter Gewusst wie: Registrieren von HTTP-Handlern und Gewusst wie: Konfigurieren einer HTTP-Handlererweiterung in IIS.

Asynchrone und synchrone HTTP-Handler

HTTP-Handler können entweder synchron oder asynchron sein. Ein synchroner Handler wird erst dann beendet, wenn die Verarbeitung der HTTP-Anforderung, für die er aufgerufen wurde, abgeschlossen ist. Bei einem asynchronen Handler werden der Prozess und das Senden einer Antwort an den Benutzer unabhängig voneinander ausgeführt. Asynchrone Handler sind nützlich für länger andauernde Anwendungsprozesse, damit der Benutzer nicht auf das Ende des Prozesses warten muss, bevor er eine Antwort vom Server erhält.

Mit asynchronen HTTP-Handlern können Sie einen externen Prozess starten, z. B. einen Methodenaufruf an einen Remoteserver. Der Handler kann mit der Verarbeitung fortfahren, ohne das Ende des externen Prozesses abwarten zu müssen. Während der Verarbeitung eines asynchronen HTTP-Handlers platziert ASP.NET den Thread, der gewöhnlich für den externen Prozess verwendet würde, wieder im Threadpool, bis der Handler vom externen Prozess einen Rückruf erhält. Dadurch wird ggf. ein Blockieren von Threads verhindert und die Leistung verbessert, da nur eine begrenzte Anzahl von Threads gleichzeitig ausgeführt werden kann. Wenn viele Benutzer synchrone, von externen Prozessen abhängige HTTP-Handler anfordern, kann es passieren, dass im Betriebssystem keine weiteren Threads verfügbar sind, da viele Threads blockiert sind und auf externe Prozesse warten.

Wenn Sie einen asynchronen Handler erstellen, müssen Sie die IHttpAsyncHandler-Schnittstelle implementieren. Außerdem müssen Sie die BeginProcessRequest-Methode implementieren, um einen asynchronen Aufruf zu initiieren, der einzelne HTTP-Anforderungen verarbeitet. Sie müssen außerdem die EndProcessRequest-Methode implementieren, um bei Beendigung des Prozesses Bereinigungscode auszuführen.

Benutzerdefinierte IHttpHandlerFactory-Klassen

Die IHttpHandlerFactory-Klasse empfängt Anforderungen und ist für die Weiterleitung der Anforderungen an den entsprechenden HTTP-Handler verantwortlich. Sie können eine benutzerdefinierte HTTP-Handlerfactory erstellen, indem Sie eine Klasse erstellen, die die IHttpHandlerFactory-Schnittstelle implementiert. Mithilfe einer benutzerdefinierten Handlerfactory können Sie die Verarbeitung von HTTP-Anforderungen genauer steuern, indem Sie verschiedene Handler erstellen, die auf Laufzeitbedingungen basieren. Mit einer benutzerdefinierten HTTP-Handlerfactory können Sie z. B. für eine Dateiart jeweils unterschiedliche HTTP-Handler für die HTTP-Anforderungsmethoden PUT und GET instanziieren.

Um eine benutzerdefinierte Erweiterung für eine Handlerfactory zu registrieren, führen Sie die Schritte zum Registrieren einer benutzerdefinierten Erweiterung für einen Handler aus. Ein Beispiel für die Erstellung und Registrierung einer Handlerfactory finden Sie unter Exemplarische Vorgehensweise: Erstellen und Registrieren von HTTP-Handlerfactorys.

HTTP-Module

Ein HTTP-Modul ist eine Assembly, die bei jeder Anforderung an die Anwendung aufgerufen wird. HTTP-Module werden als Teil der Anforderungspipeline aufgerufen und haben während der gesamten Anforderung Zugriff auf Lebenszyklusereignisse. Mithilfe von HTTP-Modulen haben Sie daher die Möglichkeit, eingehende Anforderungen zu überprüfen und basierend auf der Anforderung eine Aktion auszuführen. Außerdem können Sie auch die ausgehende Antwort überprüfen und ändern.

In IIS 6.0 ist die ASP.NET-Anforderungspipeline von der Webserver-Anforderungspipeline getrennt. In IIS 7.0 können Sie die ASP.NET-Anforderungspipeline und die Webserver-Anforderungspipeline in eine gemeinsame Anforderungspipeline integrieren. In IIS 7.0 wird dies als integrierter Modus bezeichnet. Die gemeinsame Pipeline bietet ASP.NET-Entwicklern mehrere Vorteile. Beispielsweise können Module mit verwaltetem Code für alle Anforderungen Pipelinebenachrichtigungen empfangen, und zwar auch dann, wenn die Anforderungen nicht für ASP.NET-Ressourcen bestimmt sind. Sie können IIS 7.0 jedoch auch im klassischen Modus ausführen. In diesem Modus wird die Ausführung von ASP.NET in IIS 6.0 emuliert. Weitere Informationen finden Sie unter Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 7.0.

ASP.NET-HTTP-Module sind insofern vergleichbar mit ISAPI-Filtern, als sie für alle Anforderungen aufgerufen werden. Sie werden jedoch in verwaltetem Code geschrieben und sind vollständig in den Lebenszyklus einer ASP.NET-Anwendung integriert. Sie können benutzerdefinierten Modulquellcode in den Ordner App_Code der Anwendung einfügen, oder Sie können kompilierte benutzerdefinierte Module als Assemblys in den Ordner Bin einer Anwendung einfügen.

Mithilfe von Modulen implementiert ASP.NET verschiedene Anwendungsfeatures, z. B. Formularauthentifizierung, Zwischenspeichern, Sitzungszustand und Clientskriptdienste. Beim Aktivieren eines dieser Dienste wird das Modul als Teil der Anforderung aufgerufen und führt Aufgaben durch, die außerhalb der Möglichkeiten von einzelnen Seitenanforderungen liegen. Module können Anwendungsereignisse verwenden und Ereignisse auslösen, die in der Datei Global.asax behandelt werden können. Weitere Informationen zu Anwendungsereignissen finden Sie unter Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 5.0 und 6.0 und Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 7.0.

Hinweis:

HTTP-Module unterscheiden sich von HTTP-Handlern. Ein HTTP-Handler gibt eine Antwort auf eine Anforderung zurück, die mithilfe einer Dateinamenerweiterung oder eines Satzes von Dateinamenerweiterungen identifiziert wird. Im Gegensatz dazu wird ein HTTP-Modul für alle Anforderungen und Antworten aufgerufen. Es abonniert Ereignisbenachrichtigungen in der Anforderungspipeline und ermöglicht Ihnen das Ausführen von Code in registrierten Ereignishandlern. Die Aufgaben, für die ein Modul verwendet wird, gelten allgemein für eine Anwendung und alle Anforderungen für Ressourcen in einer Anwendung.

Funktionsweise von HTTP-Modulen

Module müssen registriert werden, um Benachrichtigungen von der Anforderungspipeline empfangen zu können. Am häufigsten wird ein HTTP-Modul in der Datei Web.config der Anwendung registriert. In IIS 7.0 können Sie mithilfe der vereinheitlichten Anforderungspipeline ein Modul auch auf andere Weise registrieren, z. B. mit IIS-Manager und dem Befehlszeilentool Appcmd.exe. Weitere Informationen finden Sie unter Konfigurieren von Handlerzuordnungen in IIS 7.0 (möglicherweise in englischer Sprache) und Starten von Appcmd.exe (möglicherweise in englischer Sprache).

Wenn ASP.NET eine Instanz der HttpApplication-Klasse erstellt, die die Anwendung darstellt, werden auch Instanzen der registrierten Module erstellt. Wenn ein Modul erstellt wird, wird seine Init-Methode aufgerufen, und das Modul initialisiert sich. Weitere Informationen finden Sie unter Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 5.0 und 6.0 und Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 7.0.

Sie können in der Init-Methode eines Moduls verschiedene Anwendungsereignisse abonnieren, z. B. BeginRequest und EndRequest, indem Sie die Ereignisse an die Methoden im Modul binden.

Hinweis:

Für Module, die in der in IIS 7.0 integrierten Pipeline operieren, sollten Sie Ereignishandler in der Init-Methode registrieren.

Wenn Anwendungsereignisse ausgelöst werden, wird die entsprechende Methode im Modul aufgerufen. Die Methode kann jede erforderliche Logik ausführen, z. B. das Überprüfen der Authentifizierung oder das Protokollieren von Anforderungsinformationen. Während der Ereignisbehandlung hat das Modul Zugriff auf die Context-Eigenschaft der aktuellen Anforderung. Dadurch können Sie die Anforderung zu einer anderen Seite umleiten, die Anforderung ändern oder eine beliebige andere Anforderungsbearbeitung durchführen. Wenn das Modul z. B. die Authentifizierung überprüft, kann es zu einer Anmelde- oder Fehlerseite umleiten, falls die Anmeldeinformationen falsch sind. Andernfalls ruft ASP.NET den nächsten Prozess in der Pipeline auf, nachdem der Ereignishandler des Moduls ausgeführt wurde. Dies kann ein anderes Modul oder der entsprechende HTTP-Handler (z. B. eine ASPX-Datei) für die Anforderung sein.

HTTP-Module und Global.asax-Dateien im Vergleich

Sie können einen Großteil der Funktionalität eines Moduls in der Datei Global.asax der Anwendung implementieren, wodurch Sie auf Anwendungsereignisse reagieren können. Module haben jedoch gegenüber der Datei Global.asax den Vorteil, dass sie gekapselt sind und bei einmaliger Erstellung in vielen verschiedenen Anwendungen verwendet werden können. Durch Hinzufügen zum globalen Assemblycache und Registrieren in der Datei Machine.config lassen sich Module immer wieder in Anwendungen verwenden. Weitere Informationen finden Sie unter Globaler Assemblycache.

Hinweis:

In IIS 7.0 ermöglicht die integrierte Pipeline es verwalteten Modulen, Pipelinebenachrichtigungen für alle Anforderungen zu abonnieren, nicht nur Anforderungen für ASP.NET-Ressourcen. Ereignishandler in der Datei Global.asax werden nur für Benachrichtigungen aufgerufen, die bei Anforderungen von Ressourcen in der Anwendung auftreten. Benuterdefinierte Module können im integrierten Modus explizit so konfiguriert werden, dass sie Ereignisbenachrichtigungen nur für Anforderungen an die Anwendung empfangen. Andernfalls empfangen benutzerdefinierte Module Ereignisbenachrichtigungen für alle Anforderungen an die Anwendung. Wenn das precondition-Attribut des add-Elements im modules-Abschnitt auf "managedHandler" gesetzt ist, ist das Modul auf die Anwendung beschränkt.

Der Vorteil bei der Verwendung der Datei Global.asax besteht darin, dass Sie andere registrierte Ereignisse wie Session_Start und Session_End verarbeiten können. Darüber hinaus können Sie mit der Datei Global.asax globale Objekte instanziieren, die in der gesamten Anwendung verfügbar sind.

Sie sollten immer dann ein Modul verwenden, wenn Sie Code erstellen müssen, der von Anwendungsereignissen abhängig ist, und wenn die folgenden Bedingungen gelten:

  • Sie möchten das Modul in anderen Anwendungen wiederverwenden.

  • Sie möchten vermeiden, komplexen Code in die Datei Global.asax einzufügen.

  • Das Modul gilt für alle Anforderungen in der Pipeline (nur integrierter Modus in IIS 7.0).

Sie sollten der Datei Global.asax immer dann Code hinzufügen, wenn Sie Code erstellen müssen, der von Anwendungsereignissen abhängig ist, und wenn Sie den Code über mehrere Anwendungen hinweg verwenden möchten. Sie können die Datei Global.asax auch verwenden, wenn Sie Ereignisse abonnieren müssen, die für Module nicht verfügbar sind, z. B. Session_Start.

Erstellen eines HTTP-Moduls

Das Schreiben eines HTTP-Moduls besteht im Allgemeinen aus folgenden Schritten:

Informationen dazu, wie Sie ein Modul aus einer Anwendung, die unter IIS 6.0 oder älter ausgeführt wird, in eine Anwendung verschieben, die in IIS 7.0 ausgeführt wird, finden Sie unter Verschieben einer ASP.NET-Anwendung von IIS 6.0 nach IIS 7.0.

Zurück nach oben

Codebeispiele

Schnellstarts

HTTP-Handler und -Factorys

Themen mit Anweisungen und exemplarischen Vorgehensweisen

Gewusst wie: Registrieren von HTTP-Handlern

Gewusst wie: Konfigurieren einer HTTP-Handlererweiterung in IIS

Exemplarische Vorgehensweise: Erstellen eines synchronen HTTP-Handlers

Gewusst wie: Erstellen eines asynchronen HTTP-Handlers

Exemplarische Vorgehensweise: Erstellen und Registrieren von HTTP-Handlerfactorys

Exemplarische Vorgehensweise: Erstellen und Registrieren eines benutzerdefinierten HTTP-Moduls

Zurück nach oben

Klassenreferenz

In der folgenden Tabelle sind die wichtigsten Serverklassen für HTTP-Module und HTTP-Handler aufgeführt.

Klasse

Beschreibung

IHttpModule

Wird verwendet, um ein benutzerdefiniertes HTTP-Module zu erstellen, indem Sie die Schnittstelle implementieren und anschließend das Modul in der Datei Web.config registrieren.

IHttpHandler

Wird verwendet, um einen benutzerdefinierten synchronen HTTP-Handler zu erstellen, indem Sie eine Klasse erstellen, die die Schnittstelle implementiert.

IHttpAsyncHandler

Wird verwendet, um einen benutzerdefinierten asynchronen HTTP-Handler zu erstellen, indem Sie eine Klasse erstellen, die die Schnittstelle implementiert.

Zurück nach oben

Siehe auch

Konzepte

Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 5.0 und 6.0

Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 7.0

Referenz

Zurück nach oben