Vue d'ensemble des gestionnaires HTTP et des modules HTTP

Mise à jour : novembre 2007

Un gestionnaire HTTP ASP.NET est le processus (fréquemment appelé « point de terminaison ») d'une requête adressée à une application Web ASP.NET. Le gestionnaire le plus courant est un gestionnaire de pages ASP.NET qui traite les fichiers .aspx. Lorsque les utilisateurs demandent un fichier .aspx, la requête est traitée par la page via le gestionnaire de pages. Vous pouvez créer vos propres gestionnaires HTTP qui restituent la sortie personnalisée au navigateur.

Un module HTTP est un assembly appelé pour chaque requête effectuée sur votre application. Les modules HTTP sont appelés dans le cadre du pipeline de requête ASP.NET et ont accès aux événements du cycle de vie de l'ensemble de la requête. Les modules HTTP vous permettent d'examiner les requêtes entrantes et sortantes et de prendre des mesures en fonction des requêtes.

Cette rubrique contient les sections suivantes :

• Scénarios

• Fonctionnalités des gestionnaires HTTP et des modules HTTP

• Contexte 

• Exemples de code

• Référence de classe

Scénarios

Les utilisations classiques des gestionnaires HTTP personnalisés incluent les suivantes :

• Flux RSS   Pour créer un flux RSS pour un site Web, vous pouvez créer un gestionnaire qui émet du XML au format RSS. Vous pouvez ensuite lier une extension de nom de fichier telle que .rss au gestionnaire personnalisé. Lorsque les utilisateurs envoient une requête à votre site qui se termine par .rss, ASP.NET appelle votre gestionnaire pour traiter la requête.

• Serveur d'image   Si vous souhaitez qu'une application Web fournisse des images de différentes tailles, vous pouvez écrire un gestionnaire personnalisé pour redimensionner les images et les renvoyer à l'utilisateur comme réponse du gestionnaire.

Les utilisations classiques des modules HTTP incluent les suivantes :

• Sécurité   Étant donné que vous pouvez examiner les requêtes entrantes, un module HTTP peut exécuter l'authentification personnalisée ou d'autres contrôles de sécurité avant que la page, le service Web XML ou le gestionnaire demandé ne soit appelé. Dans les services IIS 7.0 (Internet Information Services) qui sont exécutés en mode intégré, vous pouvez étendre l'authentification par formulaire à tous les types de contenu dans une application.

• Statistiques et journalisation   Étant donné que les modules HTTP sont appelés à chaque requête, vous pouvez recueillir les statistiques de requête et les informations de journal dans un module centralisé, plutôt que dans des pages individuelles.

• En-têtes ou pieds de page personnalisés   Dans la mesure où vous pouvez modifier la réponse sortante, vous pouvez insérer le contenu dans chaque réponse de page ou de service Web XML, par exemple des informations d'en-tête personnalisé.

Retour au début

Fonctionnalités

Les fonctionnalités de gestionnaire et de module HTTP incluent les éléments suivants :

• Les interfaces IHttpHandler et IHttpModule constituent le point de départ du développement des gestionnaires et des modules.

• L'interface IHttpAsyncHandler constitue le point de départ du développement des gestionnaires asynchrones.

• Le code source des gestionnaires et des modules personnalisés peut être placé dans le dossier App_Code d'une application ou il peut être compilé et placé dans le dossier Bin d'une application.

• Les gestionnaires et modules développés pour une utilisation dans IIS 6.0 peuvent être utilisés dans IIS 7.0 avec peu ou aucune modification. Pour plus d'informations, consultez Déplacement d'une application ASP.NET d'IIS 6.0 vers IIS 7.0.

• Les modules peuvent s'abonner à plusieurs notifications de pipeline de requête. Les modules peuvent recevoir des notifications d'événement de l'objet HttpApplication.

• Dans IIS 7.0, le pipeline de requête est intégré au pipeline de requête du serveur Web. Les modules HTTP peuvent être utilisés pour toutes les requêtes au serveur Web et non pas seulement pour les requêtes ASP.NET.

Retour au début

Contexte

Gestionnaires HTTP

Un gestionnaire HTTP ASP.NET est le processus qui s'exécute en réponse à une requête adressée à une application Web ASP.NET. Le gestionnaire le plus courant est un gestionnaire de pages ASP.NET qui traite les fichiers .aspx. Lorsque les utilisateurs demandent un fichier .aspx, la requête est traitée par le gestionnaire de pages.

Le gestionnaire de pages ASP.NET n'est qu'un type de gestionnaire. ASP.NET inclut plusieurs autres gestionnaires intégrés, comme le gestionnaire de service Web pour les fichiers .asmx.

Gestionnaires HTTP intégrés dans ASP.NET

ASP.NET mappe les requêtes HTTP aux gestionnaires HTTP en fonction de l'extension du fichier. Chaque gestionnaire HTTP peut traiter des URL HTTP individuelles ou des groupes d'extension d'URL dans une application. ASP.NET inclut plusieurs gestionnaires HTTP intégrés (voir le tableau suivant).

Création d'un gestionnaire HTTP personnalisé

Pour créer un gestionnaire HTTP personnalisé, créez une classe qui implémente l'interface IHttpHandler afin de créer un gestionnaire synchrone. Vous pouvez également implémenter IHttpAsyncHandler pour créer un gestionnaire asynchrone. Les deux interfaces de gestionnaire requièrent l'implémentation de la propriété IsReusable et de la méthode ProcessRequest. La propriété IsReusable spécifie si l'objet IHttpHandlerFactory (l'objet qui appelle réellement le gestionnaire approprié) peut mettre le gestionnaire dans un pool et le réutiliser pour améliorer les performances. Si le gestionnaire ne peut pas être regroupé, la fabrique doit créer une instance du gestionnaire à chaque fois que celui-ci est nécessaire.

La méthode ProcessRequest est chargée de traiter les requêtes HTTP individuelles. Dans cette méthode, vous écrivez le code qui génère la sortie pour le gestionnaire.

Les gestionnaires HTTP ont accès au contexte d'application. Cela inclut l'identité de l'utilisateur demandeur (si connu), l'état de l'application et les informations sur la session. Lorsqu'un gestionnaire HTTP est demandé, ASP.NET appelle la méthode ProcessRequest du gestionnaire approprié. Le code que vous écrivez dans la méthode ProcessRequest du gestionnaire crée une réponse qui est renvoyée au navigateur effectuant la requête.

Mappage à une extension de nom de fichier

Lorsque vous créez un fichier de classe comme votre gestionnaire HTTP, le gestionnaire peut répondre à n'importe quelle extension de nom de fichier qui n'est pas déjà mappée dans IIS et ASP.NET. Par exemple, si vous créez un gestionnaire HTTP pour générer un flux RSS, vous pouvez mapper votre gestionnaire à l'extension de nom de fichier .rss. Vous devez mapper l'extension à ASP.NET dans IIS pour qu'ASP.NET sache quel gestionnaire utiliser pour votre extension de nom de fichier personnalisée. Puis, dans l'application, vous devez mapper l'extension au gestionnaire personnalisé.

Par défaut, ASP.NET mappe l'extension de nom de fichier .ashx à un gestionnaire HTTP. Si vous ajoutez la directive @ WebHandler à un fichier de classe, ASP.NET mappe automatiquement l'extension de nom de fichier .ashx au gestionnaire HTTP par défaut. Cela se rapproche de la façon dont ASP.NET mappe l'extension de nom de fichier .aspx au gestionnaire de pages ASP.NET lorsque la directive @ Page est utilisée. Par conséquent, si vous créez une classe de gestionnaire HTTP avec l'extension de nom de fichier .ashx, le gestionnaire est inscrit automatiquement avec IIS et ASP.NET.

Si vous souhaitez créer une extension de nom de fichier personnalisée pour un gestionnaire, vous devez inscrire explicitement l'extension avec IIS et ASP.NET. L'avantage de ne pas utiliser l'extension de nom de fichier .ashx est que le gestionnaire est ensuite réutilisable pour les différents mappages d'extension. Par exemple, dans une application, le gestionnaire personnalisé peut répondre aux requêtes qui se terminent par l'extension .rss. Dans une autre application, il peut répondre aux requêtes qui se terminent par .feed. Autre exemple : le gestionnaire peut être mappé à deux extensions de nom de fichier de la même application, mais il peut créer des réponses différentes en fonction de l'extension.

Le processus d'inscription de l'extension de nom de fichier personnalisée d'un gestionnaire est différent dans IIS 7.0 et dans les versions antérieures d'IIS. Pour plus d'informations, consultez Comment : enregistrer des gestionnaires HTTP et Comment : configurer une extension du gestionnaire HTTP dans IIS.

Gestionnaires HTTP asynchrones et synchrones

Un gestionnaire HTTP peut être soit synchrone, soit asynchrone. Un gestionnaire synchrone ne retourne pas avant d'avoir fini de traiter la requête HTTP pour laquelle il a été appelé. Un gestionnaire asynchrone exécute un processus indépendamment de l'envoi d'une réponse à l'utilisateur. Les gestionnaires asynchrones sont utiles lorsque vous devez démarrer un processus d'application qui peut durer un certain temps et que l'utilisateur ne doit pas attendre la fin du processus pour obtenir une réponse du serveur.

Les gestionnaires HTTP asynchrones vous permettent de démarrer un processus externe, tel qu'un appel de méthode à un serveur distant. Le gestionnaire peut ensuite poursuivre le traitement sans attendre la fin du processus externe. Pendant le traitement d'un gestionnaire HTTP asynchrone, ASP.NET replace le thread qui serait en principe utilisé pour le processus externe dans le pool de threads, jusqu'à ce que le gestionnaire reçoive un rappel du processus externe. Cela permet d'éviter le blocage du thread et d'améliorer les performances car seul un nombre limité de threads peut être exécuté simultanément. Si plusieurs utilisateurs demandent des gestionnaires HTTP synchrones qui dépendent de processus externes, le système d'exploitation peut rapidement manquer de threads car beaucoup d'entre eux sont bloqués, en attente d'un processus externe.

Lorsque vous créez un gestionnaire asynchrone, vous devez implémenter l'interface IHttpAsyncHandler. Vous devez également implémenter la méthode BeginProcessRequest pour initialiser un appel asynchrone qui traite les requêtes HTTP individuelles. Vous devez également implémenter la méthode EndProcessRequest pour exécuter le code de nettoyage lorsque le processus se termine.

Classes IHttpHandlerFactory personnalisées

La classe IHttpHandlerFactory reçoit des requêtes et est chargée d'envoyer une requête au gestionnaire HTTP approprié. Vous pouvez créer une fabrique de gestionnaires HTTP personnalisée en créant une classe qui implémente l'interface IHttpHandlerFactory. Une fabrique de gestionnaires personnalisée permet d'effectuer un contrôle plus fin sur le traitement des requêtes HTTP en créant différents gestionnaires selon les conditions d'exécution. Par exemple, avec une fabrique de gestionnaires HTTP personnalisée, vous pouvez instancier un gestionnaire HTTP pour un type de fichier si la méthode de la requête HTTP est PUT et un autre gestionnaire si la méthode est GET.

Pour inscrire une extension personnalisée pour une fabrique de gestionnaires, suivez les étapes d'inscription d'une extension personnalisée pour un gestionnaire. Pour obtenir un exemple de création et d'inscription d'une fabrique de gestionnaires, consultez Procédure pas à pas : création et inscription de fabriques de gestionnaires HTTP.

Modules HTTP

Un module HTTP est un assembly appelé pour chaque requête effectuée sur votre application. Les modules HTTP sont appelés dans le cadre du pipeline de requête ASP.NET et ont accès aux événements du cycle de vie de l'ensemble de la requête. Les modules HTTP vous permettent par conséquent d'examiner les requêtes entrantes et de prendre des mesures en fonction des requêtes. Ils vous laissent également examiner la réponse sortante et la modifier.

Dans ISS 6.0, le pipeline de requête ASP.NET est distinct du pipeline de requête du serveur Web. Dans IIS 7.0, le pipeline de requête ASP.NET et le pipeline de requête du serveur Web peuvent être intégrés dans un pipeline de requête commun. Dans IIS 7.0, cela s'appelle le mode intégré. Le pipeline unifié a plusieurs avantages pour les développeurs ASP.NET. Par exemple, il permet aux modules de code managé de recevoir des notifications de pipeline pour toutes les requêtes, même si les requêtes ne sont pas destinées à des ressources ASP.NET. Toutefois, si vous le souhaitez, vous pouvez exécuter IIS 7.0 en mode classique, ce qui émule ASP.NET, exécuté dans ISS 6.0. Pour plus d'informations, consultez Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 7.0.

Les modules HTTP ASP.NET sont semblables aux filtres ISAPI étant donné qu'ils sont appelés pour toutes les requêtes. Toutefois, ils sont écrits en code managé et sont pleinement intégrés au cycle de vie d'une application ASP.NET. Vous pouvez mettre le code source du module personnalisé dans le dossier App_Code de votre application ou vous pouvez mettre des modules personnalisés compilés en tant qu'assemblys dans le dossier Bin d'une application.

ASP.NET utilise des modules pour implémenter les différentes fonctionnalités de l'application, notamment l'authentification par formulaire, la mise en cache, les états de session et les services de script client. Dans chaque cas, lorsque ces services sont activés, le module est appelé dans le cadre d'une requête et exécute des tâches en dehors d'une requête de page unique. Les modules peuvent utiliser des événements d'application et déclencher des événements qui peuvent être gérés dans le fichier Global.asax. Pour plus d'informations sur les événements d'application, consultez Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0 et Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 7.0.

Remarque :

Les modules HTTP diffèrent des gestionnaires HTTP. Un gestionnaire HTTP retourne une réponse à une requête identifiée par une extension de nom de fichier ou une famille d'extensions de nom de fichier. Par opposition, un module HTTP est appelé pour toutes les requêtes et les réponses. Il s'abonne aux notifications d'événement dans le pipeline de requête et vous permet d'exécuter du code dans les gestionnaires d'événements inscrits. Les tâches pour lesquelles un module est utilisé sont générales à une application et à toutes les requêtes pour les ressources dans l'application.

Mode de fonctionnement des modules HTTP

Les modules doivent être inscrits pour recevoir des notifications du pipeline de requête. L'inscription d'un module HTTP dans le fichier Web.config de l'application est la méthode d'inscription la plus courante. Dans IIS 7.0, le pipeline de requête unifié vous permet également d'inscrire un module d'autres manières, notamment via le Gestionnaire des services IIS et l'outil en ligne de commande Appcmd.exe. Pour plus d'informations, consultez Configuration des mappages de gestionnaires dans IIS 7.0 et Lancer Appcmd.exe (en anglais).

Lorsque ASP.NET crée une instance de la classe HttpApplication qui représente votre application, les instances de tous modules ayant été enregistrés sont créées. Lorsqu'un module est créé, sa méthode Init est appelée et le module s'initialise. Pour plus d'informations sur ASP.NET, consultez Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0 et Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 7.0.

Dans la méthode Init d'un module, vous pouvez vous abonner à différents événements d'application tels que BeginRequest ou EndRequest en liant les événements aux méthodes du module.

Remarque :
Pour les modules qui fonctionnent dans le pipeline intégré de IIS 7.0, vous devez inscrire des gestionnaires d'événements dans la méthode Init.

Lorsque les événements d'application sont déclenchés, la méthode appropriée dans votre module est appelée. La méthode peut exécuter la logique requise, telle que la vérification de l'authentification ou la journalisation des informations de requête. Lors de la gestion d'événements, le module a accès à la propriété Context de la requête actuelle. Cela vous permet de rediriger la requête vers une autre page, de modifier la requête ou d'exécuter toute autre manipulation de requête. Par exemple, si le module vérifie l'authentification, il peut rediriger vers une page de journalisation ou d'erreurs si les informations d'identification ne sont pas correctes. Sinon, lorsque l'exécution du gestionnaire d'événements du module est terminée, ASP.NET appelle le processus suivant dans le pipeline. Il peut s'agir d'un autre module ou du gestionnaire HTTP approprié (tel qu'un fichier .aspx) pour la requête.

Modules HTTP et fichiers Global.asax

Vous pouvez implémenter de nombreuses fonctionnalités d'un module dans le fichier Global.asax de l'application, ce qui vous permet de répondre aux événements d'application. Toutefois, les modules ont un avantage sur le fichier Global.asax car ils sont encapsulés et peuvent être créés une seule fois et utilisés dans différentes applications. En les ajoutant au Global Assembly Cache (GAC) et en les inscrivant dans le fichier Machine.config, vous pouvez les réutiliser dans les applications. Pour plus d'informations, consultez Global Assembly Cache.

Remarque :

Dans IIS 7.0, le pipeline intégré autorise les modules managés à s'abonner aux notifications de pipeline pour toutes les requêtes et pas seulement les requêtes pour les ressources ASP.NET. Les gestionnaires d'événements dans le fichier Global.asax sont appelés uniquement pour les notifications pendant les requêtes de ressources dans l'application. Les modules personnalisés en mode intégré peuvent être explicitement limités à la réception des notifications d'événement uniquement pour les requêtes envoyées à l'application. Sinon, les modules personnalisés reçoivent les notifications d'événement pour toutes les requêtes envoyées à l'application. Si l'attribut precondition de l'élément add de la section modules a la valeur "managedHandler", le module est limité à l'application.

L'avantage d'utiliser le fichier Global.asax est qu'il vous permet de gérer d'autres événements inscrits tels que Session_Start et Session_End. En outre, le fichier Global.asax vous permet également d'instancier des objets globaux disponibles dans l'ensemble de l'application.

Vous devez utiliser un module à chaque fois que vous devez créer du code qui dépend des événements d'application et lorsque les conditions suivantes sont remplies :

• Vous souhaitez réutiliser le module dans d'autres applications.

• Vous souhaitez éviter de mettre du code complexe dans le fichier Global.asax.

• Le module s'applique à toutes les requêtes dans le pipeline (mode intégré de IIS 7.0 uniquement).

Vous devez ajouter le code dans le fichier Global.asax à chaque fois que vous devez créer du code qui dépend des événements d'application et que vous n'avez pas à le réutiliser pour plusieurs applications. Vous pouvez également utiliser le fichier Global.asax lorsque vous devez vous abonner aux événements qui ne sont pas disponibles pour les modules, tels que Session_Start.

Création d'un module HTTP

Le processus général d'écriture d'un module HTTP est le suivant :

• Définissez une classe qui implémente l'interface IHttpModule.

• Ajoutez un gestionnaire pour la méthode Init. La méthode d'initialisation doit initialiser votre module et vous abonner aux événements d'application nécessaires. Par exemple, si vous souhaitez ajouter quelque chose aux réponses, vous pouvez vous abonner à l'événement EndRequest. Si vous souhaitez exécuter la logique d'authentification personnalisée, vous devez vous abonner à l'événement AuthenticateRequest. Pour plus d'informations sur les événements d'application, consultez Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0.

• Écrivez le code des événements auxquels vous vous êtes abonné.

• À titre facultatif, implémentez la méthode Dispose si le module requiert un nettoyage.

• Inscrivez le module dans le fichier Web.config. Pour plus d'informations, consultez Procédure pas à pas : création et inscription d'un module HTTP personnalisé.

Pour plus d'informations sur le déplacement d'un module d'une application qui s'exécute dans ISS 6.0 ou les versions antérieures vers une application qui s'exécute dans IIS 7.0, consultez Déplacement d'une application ASP.NET d'IIS 6.0 vers IIS 7.0.

Retour au début

Exemples de code

Démarrages rapides

Gestionnaires et fabriques HTTP

Rubriques Comment et Procédure pas à pas

Comment : enregistrer des gestionnaires HTTP

Comment : configurer une extension du gestionnaire HTTP dans IIS

Procédure pas à pas : création d'un gestionnaire HTTP synchrone

Comment : créer un gestionnaire HTTP asynchrone

Procédure pas à pas : création et inscription de fabriques de gestionnaires HTTP

Procédure pas à pas : création et inscription d'un module HTTP personnalisé

Retour au début

Référence de classe

Le tableau suivant répertorie les classes de serveur clés pour les modules et les gestionnaires HTTP.

Retour au début

Voir aussi

Concepts

Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0

Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 7.0

Référence

Retour au début