Conception de modules HTTP Native-Code

Les modules HTTP dans IIS 7 permettent aux développeurs d’étendre ou de remplacer les principales fonctionnalités IIS. Par exemple, vous pouvez écrire un module d’authentification digest qui remplace le module inclus dans IIS 7. Bien que certaines des fonctionnalités fournies par les modules de code natif puissent ressembler à des fonctionnalités qui étaient auparavant disponibles avec les filtres ISAPI, les modules de code natif sont conçus différemment et fournissent un ensemble de fonctionnalités beaucoup plus riche que les filtres ISAPI.

Configuration requise pour les modules HTTP Native-Code

Ajout d’une fonction d’inscription exportée

Les modules HTTP sont nécessaires pour exporter une fonction RegisterModule . Vous pouvez exporter cette fonction en créant un fichier de définition de module (.def) pour votre projet, ou vous pouvez compiler le module à l’aide du commutateur /EXPORT:RegisterModule .

Spécification des notifications et de la priorité du module

Lorsque vous créez votre RegisterModule fonction, vous spécifiez un masque de bits qui contient une liste de notifications que votre module au niveau de la demande traitera (pour plus d’informations, consultez Constantes de traitement des demandes). Par exemple, un module au niveau de la demande peut spécifier qu’il fournira des méthodes pour traiter la notification RQ_BEGIN_REQUEST et la RQ_MAP_PATH post-notification. De même, un module de niveau global peut spécifier qu’il fournira des méthodes pour traiter les GL_APPLICATION_START et les notifications GL_APPLICATION_STOP .

La RegisterModule fonction vous permet également de spécifier la priorité pour le module. Les priorités disponibles sont PRIORITY_ALIAS_FIRST, PRIORITY_ALIAS_HIGH, PRIORITY_ALIAS_MEDIUM, PRIORITY_ALIAS_LOWet PRIORITY_ALIAS_LAST. Lorsque les modules sont inscrits, ils sont traités par ordre de priorité et de paramètres de configuration. Par exemple, si vous créez un module HTTP qui s’inscrit en tant que module de priorité moyenne, votre module ne sera pas traité tant que tous les modules à haute priorité n’auront pas été traités. Vous pouvez configurer votre module pour qu’il soit traité avant d’autres modules de priorité moyenne, et votre module sera traité avant les modules de faible priorité.

Notes

L’ordre des niveaux de priorité est inversé pour les RQ_SEND_RESPONSE notifications.

Création de modules Request-Level

Création d’une fabrique de modules

Les modules de niveau requête de code natif doivent fournir une fabrique de modules qui crée un instance de la classe CHttpModule. La fabrique de modules héritera de l’interface IHttpModuleFactory .

Pour plus d’informations sur la création d’une fabrique de modules, consultez l’exemple de code dans Procédure pas à pas : création d’un module HTTP Request-Level à l’aide de code natif.

Création d’une classe dérivée de CHttpModule

La fonctionnalité de traitement main pour les modules HTTP au niveau de la demande est fournie par le biais d’un module dérivé de la classe de baseCHttpModule. Cette classe doit contenir une méthode de rappel pour chaque notification ou post-notification répertoriée dans la RegisterModule fonction . Par exemple, si votre module est inscrit pour la notification RQ_AUTHENTICATE_REQUEST et la RQ_AUTHORIZE_REQUEST post-notification, votre classe doit contenir les méthodes OnAuthenticateRequest et OnPostAuthorizeRequest .

Retour à partir de méthodes CHttpModule

Lorsque le traitement des méthodes de la CHttpModule classe est terminé, chaque méthode doit retourner une valeur d’énumération REQUEST_NOTIFICATION_STATUS . Cette valeur détermine la façon dont IIS gère la condition de sortie des méthodes de classe. Par exemple, une valeur de retour de RQ_NOTIFICATION_CONTINUE informe IIS de continuer à traiter la demande. En revanche, une valeur de retour RQ_NOTIFICATION_FINISH_REQUEST indique à IIS de cesser le traitement sur la demande actuelle.

Nettoyage CHttpModule

Une fois le traitement d’un module terminé, IIS appelle la méthode CHttpModule::D ispose du module pour supprimer la classe de la CHttpModule mémoire.

Création d’un module Global-Level

Création d’une classe dérivée de CGlobalModule

La fonctionnalité de traitement main pour les modules HTTP de niveau global est fournie via un module dérivé de la classe CGlobalModule de base. Cette classe doit contenir une méthode de rappel pour chaque notification répertoriée dans la RegisterModule fonction . Par exemple, si votre module est inscrit pour le GL_APPLICATION_START et les notifications GL_APPLICATION_STOP , votre classe doit contenir les méthodes OnGlobalApplicationStart et OnGlobalApplicationStop .

Retour à partir de méthodes CGlobalModule

Lorsque le traitement des méthodes de la CGlobalModule classe est terminé, chaque méthode doit retourner une valeur d’énumération GLOBAL_NOTIFICATION_STATUS . Cette valeur détermine la façon dont IIS gère la condition de sortie des méthodes de classe. Par exemple, une valeur de retour de GL_NOTIFICATION_CONTINUE informe IIS de continuer à traiter la notification. En revanche, une valeur de retour de GL_NOTIFICATION_HANDLED indique à IIS d’arrêter le traitement de la notification actuelle.

Nettoyage CGlobalModule

Une fois le traitement d’un module terminé, IIS appelle la méthode CGlobalModule::Terminate du module. Votre module doit utiliser cette méthode pour supprimer votre CGlobalModule classe de la mémoire.

Voir aussi

Procédure pas à pas : création d’un module HTTP Request-Level à l’aide de code natif
Procédure pas à pas : création d’un module HTTP Global-Level à l’aide de code natif
Création de modules HTTP Native-Code