Intégration de ASP.NET à IIS 7

par Mike Volodarsky

Introduction

Depuis sa première version, ASP.NET a été la plateforme de choix pour le développement d’applications web sur la plateforme Windows/IIS. ASP.NET 2.0 a pris le développement d’applications web à un nouveau niveau, ce qui permet aux développeurs de créer des applications plus puissantes que jamais.

IIS-7 fait passer ASP.NET au niveau supérieur, en intégrant le modèle d’extensibilité du runtime ASP.NET au serveur principal. Cela permet aux développeurs d’étendre entièrement le serveur IIS avec la richesse de ASP.NET 2.0 et du .NET Framework, au lieu d’utiliser les API IIS C++ moins compatibles. Les applications ASP.NET existantes bénéficient également immédiatement d’une intégration plus étroite en étant en mesure d’utiliser des fonctionnalités d’ASP.NET existantes telles que l’authentification par formulaire, les rôles et la mise en cache de sortie pour tous les types de contenu.

Si IIS fournit l’intégration améliorée ASP.NET par défaut, IIS prend en charge les modes d’intégration nouveaux et anciens ASP.NET qui peuvent être utilisés côte à côte sur le même serveur.

Cet article décrit les améliorations introduites par le mode d’intégration ASP.NET, l’architecture des deux modes et explique comment sélectionner et configurer les modes d’intégration pour les applications ASP.NET.

Améliorations de ASP.NET sur IIS 7 et versions ultérieures

Une meilleure intégration ASP.NET dans IIS améliore les applications existantes et permet également aux nouvelles applications de tirer parti des fonctionnalités de ASP.NET de la manière suivante :

• ASP.NET services peuvent être utilisés pour tous les types de contenu. Par le passé, ASP.NET fonctionnalités telles que l’authentification par formulaire, les rôles, l’autorisation d’URL et la mise en cache de sortie n’étaient disponibles que pour ASP.NET types de contenu tels que les pages ASPX. Les fichiers statiques, les pages ASP et d’autres types de contenu n’ont pas pu tirer parti de ces services.

Dans IIS, tous les services ASP.NET sont fournis uniformément à tout le contenu. Par exemple, vous pouvez protéger tout votre contenu web, y compris les images et les pages ASP, avec votre solution de contrôle d’accès ASP.NET 2.0 existante basée sur ASP.NET l’authentification par formulaire, l’appartenance et les contrôles de connexion.

• Étendez entièrement IIS avec ASP.NET. Les versions précédentes d’IIS nécessitent fréquemment l’extensibilité du serveur pour être développées à l’aide du filtre ISAPI natif ou du mode d’extensibilité d’extension, en raison des limitations du runtime de ASP.NET.

IIS permet aux modules ASP.NET de se connecter directement au pipeline de serveur, avec la même fidélité au runtime que les modules développés avec l’API serveur native (C++). Les modules ASP.NET peuvent s’exécuter dans toutes les phases d’exécution du pipeline de traitement des requêtes et peuvent être exécutés dans n’importe quel ordre par rapport aux modules natifs. L’API ASP.NET est également développée pour permettre plus de contrôle sur le traitement des requêtes que possible précédemment.

• Runtime de serveur unifié. L’intégration ASP.NET plus étroite permet également d’unifier la plupart des fonctionnalités entre IIS et ASP.NET.

IIS fournit une configuration unifiée pour les modules et les gestionnaires IIS et ASP.NET. De nombreuses autres fonctionnalités, notamment les erreurs personnalisées et le suivi, ont été unifiées pour permettre une meilleure gestion et une conception cohérente des applications.

Architecture d'intégration ASP.NET

Dans IIS 6.0 et versions précédentes, ASP.NET a été implémenté en tant qu’extension ISAPI IIS.

Dans ces versions antérieures, IIS a traité une requête vers un type de contenu ASP.NET, puis transféré cette requête à la DLL ISAPI ASP.NET, qui a hébergé le pipeline de requête et l’infrastructure de page ASP.NET. Les requêtes adressées à non-ASP.NET contenu, telles que les pages ASP ou les fichiers statiques, ont été traitées par IIS ou d’autres extensions ISAPI et n’étaient pas visibles pour ASP.NET.

La principale limitation de ce modèle était que les services fournis par les modules ASP.NET et le code d’application ASP.NET personnalisé n’étaient pas disponibles pour les requêtes non-ASP.NET. De plus, les modules ASP.NET n’ont pas pu affecter certaines parties du traitement des requêtes IIS qui se sont produites avant et après le chemin d’exécution de ASP.NET.

Figure 1 : Pipelines IIS 6.0 &ASP.NET

Dans IIS, le ASP.NET pipeline de traitement des requêtes superpose directement le pipeline IIS, fournissant essentiellement un wrapper dessus au lieu de le connecter.

IIS traite les requêtes qui arrivent pour n’importe quel type de contenu, avec des modules IIS natifs et des modules ASP.NET fournissant le traitement des requêtes à toutes les étapes. Cela permet aux services fournis par des modules ASP.NET, tels que l’authentification par formulaire ou le cache de sortie, d’être utilisés pour les requêtes adressées aux pages ASP, aux pages PHP, aux fichiers statiques, etc.

La possibilité de se connecter directement au pipeline de serveur permet à ASP.NET modules de remplacer, d’exécuter avant ou d’exécuter après toute fonctionnalité IIS. Cela permet, par exemple, un module d’authentification de base ASP.NET personnalisé écrit pour utiliser le service d’appartenance et la base de données utilisateur SQL Server pour remplacer la fonctionnalité d’authentification IIS De base intégrée qui fonctionne uniquement avec les comptes Windows.

En outre, les API étendues ASP.NET utilisent l’intégration directe pour permettre davantage de tâches de traitement des requêtes. Par exemple, les modules ASP.NET peuvent modifier les en-têtes de requête avant que d’autres composants traitent la requête, en insérant un en-tête Accept-Language avant l’exécution des applications ASP, ce qui force le contenu localisé à être renvoyé au client en fonction de la préférence utilisateur.

Figure 2 : IIS 7 et versions ultérieures en mode intégré

En raison de l’intégration du runtime, IIS et ASP.NET peuvent utiliser la même configuration pour activer et commander des modules serveur et configurer des mappages de gestionnaires. D’autres fonctionnalités unifiées incluent le suivi, les erreurs personnalisées et la mise en cache de sortie.

Compatibilité

Plus particulièrement, l’architecture gère l’architecture et les API d’exécution ASP.NET, ce qui permet à des applications et services ASP.NET existants de fonctionner lors de l’installation. Avec quelques modifications, les applications et services ASP.NET existants peuvent tirer parti des nouvelles fonctionnalités de ASP.NET.

De même, les développeurs peuvent continuer à écrire de nouvelles applications pour des API familières ASP.NET tout en tirant parti des avantages de l’intégration du runtime.

IIS continue de fournir le mode de ASP.NET Classique pour les applications ASP.NET qui ont des exigences de compatibilité spécifiques qui ne sont pas remplies par le mode intégré. Les administrateurs peuvent sélectionner le mode d’intégration souhaité par pool d’applications, ce qui permet aux applications qui utilisent à la fois les nouveaux et les modes de ASP.NET Classic de fonctionner côte à côte sur le même serveur.

Migration d’applications ASP.NET vers IIS 7 et versions ultérieures

Sur IIS, ASP.NET est configuré pour fonctionner en mode intégré par défaut. Cela permet à votre application de tirer parti des améliorations du mode intégré avec des modifications minimales.

En raison de l’unification de la configuration, certaines applications peuvent nécessiter une migration pour fonctionner correctement en mode intégré. Par défaut, le serveur fournit de l’aide à la migration. Il détecte les applications qui nécessitent la migration et retourne un message d’erreur vous demandant de migrer l’application.

La configuration suivante provoque l’erreur de migration :

1. Le fichier web.config d’application définit la configuration <httpModules>.
   L’application charge de nouveaux modules ASP.NET ou supprime les modules existants.
   En mode intégré, les modules ASP.NET sont spécifiés avec des modules natifs dans la section de configuration unifiée <system.webServer>/<modules>.
   Les modules ASP.NET spécifiés dans la section de configuration <system.web>/<httpModules> doivent être déplacés vers la nouvelle section de configuration pour prendre effet. Par la suite, de nouveaux modules ASP.NET doivent être ajoutés directement à la section unifiée <modules>.
2. Le fichier Web.config d’application définit la <httpHandlers> configuration.
   L’application utilise des mappages de gestionnaires personnalisés pour certains types de contenu.
   En mode intégré, ASP.NET mappages de gestionnaires doivent être spécifiés dans la section de configuration unifiée <system.webServer>/<handlers>. Par la suite, de nouveaux mappages de gestionnaires ASP.NET doivent être ajoutés directement à la section unifiée <handlers>.
   Cette section remplace à la fois la configuration ASP.NET <httpHandlers> et la configuration des scripts IIS, dont les deux doivent être configurées précédemment pour configurer un mappage de gestionnaire de ASP.NET.
3. Le fichier web.config d’application définit <l’identité impersonate="true" /> configuration.
   L’application emprunte l’identité des informations d’identification du client, ce qui est le plus courant avec les applications intranet. En mode intégré, l’emprunt d’identité du client n’est pas disponible dans certaines phases de traitement des requêtes anticipées. Dans la majorité des cas, ce n’est pas un problème et vous pouvez désactiver l’erreur de migration. Sinon, vous devez configurer cette application pour qu’elle s’exécute à l’aide du mode de ASP.NET Classique.

Lorsque l’erreur de migration est générée, elle peut généralement migrer la configuration de l’application (recommandée dans les cas 1 et 2, ci-dessus) ou déplacer l’application pour utiliser le mode classique ASP.NET (dans le cas 3).

Migration de la configuration de l’application

IIS migre l’application à l’aide de l’outil de ligne de commande AppCmd.exe pour effectuer la migration. Le message d’erreur de migration contient la commande exécutée dans la fenêtre de ligne de commande, que vous devez exécuter avec les droits utilisateur d’administrateur, pour migrer instantanément votre application en mode intégré.

Le format de base de la commande de migration est le suivant :

%windir%\system32\inetsrv\APPCMD.EXE migrate config <Application Path>

Où <le chemin d’accès de l’application> est le chemin d’accès virtuel de l’application qui contient le nom du site, tel que « Site web/application par défaut1 ».

Une fois la migration terminée, votre application s’exécute dans les modes Intégré et Classique sans aucun problème.

Retour au mode d’intégration de ASP.NET classique

Si vous préférez revenir au mode classique ASP.NET, déplacez votre application vers un pool d’applications configuré pour s’exécuter en mode Classique. D’autres applications continuent à s’exécuter en mode intégré côte à côte avec l’application en mode Classique.

Pour plus d’informations sur le déplacement d’une application vers le mode de ASP.NET classique, consultez Modification des modes d’ASP.NET pour une application.

Désactivation du message d’erreur de migration

Si vous avez migré manuellement votre configuration ou que vous souhaitez rester en mode intégré sans migrer votre configuration (non recommandé), vous pouvez désactiver le message d’erreur de migration en ajoutant ce qui suit au fichier Web.config de l’application :

<system.webServer> 
    <validation validateIntegratedModeConfiguration="false" />    
</system.webServer>

Si vous désactivez manuellement le message d’erreur de migration, vous devez vous assurer que votre application fonctionne correctement en mode intégré, car le serveur ne fournira plus d’avertissements sur la configuration non prise en charge.

Modification des modes d’ASP.NET pour une application

Si votre application ne fonctionne pas correctement en mode ASP.NET intégré, vous pouvez la déplacer vers le mode de ASP.NET classique en le déplaçant vers un autre pool d’applications. Chaque pool d’applications est configuré individuellement pour utiliser le mode d’intégration de ASP.NET souhaité. Cela vous permet d’exécuter des groupes d’applications qui utilisent différents modes d’intégration ASP.NET côte à côte sur le même serveur.

Pour modifier le mode d’intégration ASP.NET pour une application :

1. Recherchez ou créez un pool d’applications configuré pour utiliser le mode souhaité.
   Par défaut, tous les nouveaux pools d’applications s’exécutent en mode intégré.
   La configuration ASP.NET fournit un pool d’applications nommé « Classic .NET AppPool » qui s’exécute en mode d’intégration de ASP.NET classique. Vous pouvez utiliser ce pool d’applications pour les applications qui ne doivent pas s’exécuter en mode intégré.
   Vous pouvez également modifier le mode ASP.NET du pool d’applications existant à l’aide de l’outil d’administration IIS ou de l’outil en ligne de commande AppCmd.exe, ou en modifiant manuellement la configuration du pool d’applications.
2. Définissez l’application pour utiliser ce pool d’applications.
   Chaque application est configurée pour utiliser un pool d’applications particulier. Par défaut, toutes les applications utilisent le pool d’applications par défaut nommé « DefaultAppPool », qui s’exécute en mode intégré.
   Vous pouvez modifier le pool d’applications d’une application à l’aide de l’outil d’administration IIS ou de l’outil en ligne de commande AppCmd.exe, ou en modifiant manuellement la configuration de l’application.

Sélection d’une version ASP.NET pour une application

Historiquement, IIS a pris en charge plusieurs versions de ASP.NET/CLR côte à côte. Par exemple, IIS permet au même serveur d’exécuter des applications ASP.NET à l’aide de .NET Framework v1.1 et v2.0. Cette prise en charge a été fournie en mappant une version correspondante de ASPNET_isapi.dll pour traiter les requêtes du contenu ASP.NET à l’aide de la configuration des scriptsMAPs IIS.

Par exemple, vous pouvez utiliser la configuration de scriptmap suivante pour activer la prise en charge côte à côte :

1. ASP.NET v1.1 application on /app1:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
2. ASP.NET v2.0 application on /app2:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

Lorsque l’application reçoit une requête *.aspx, IIS charge le aspnet_isapi.dll spécifié, qui charge la version CLR correcte dans le processus de travail et traite la requête.

ASP.NET fournit également les méthodes suivantes pour configurer des mappages de script côte à côte :

1. ASP.NET extension MMC. Lorsque vous choisissez la version de ASP.NET à utiliser, l’extension configure automatiquement les mappages de script pour que l’application pointe vers la version correcte de aspnet_isapi.dll.
2. ASP.NET aspnet_regiis.exe. Utilisez les options –i et –r pour installer les mappages de script qui pointent vers la version ASP.NET correspondante.

Malheureusement, en raison de la limitation de la possibilité de charger une seule version CLR dans un seul processus de travail, vous devez vous assurer que deux applications qui utilisent différentes versions de ASP.NET ne sont jamais configurées pour exister dans le même pool d’applications. Lorsque cette erreur courante est effectuée, la première requête charge le CLR de la aspnet_isapi.dll correspondante, et les requêtes suivantes adressées à l’autre version du même pool d’applications échouent.

IIS reconnaît que le pool d’applications est la version ASP.NET que vous sélectionnez pour exécuter une application sous. Par conséquent, la version du CLR/ASP.NET chargée dans le pool d’applications est explicitement configurée dans la configuration du pool d’applications. Par défaut, IIS précharge le CLR spécifié par ce paramètre lors du chargement du processus de travail (sauf si la version est configurée pour être vide).

Étant donné que les pools d’applications sont la limite de contrôle de version .NET Framework, vous pouvez modifier la version d’une application ASP.NET en procédant comme suit :

1. Déplacez l’application vers un pool d’applications qui utilise la version de ASP.NET souhaitée.
   Par défaut, les applications utilisent le pool d’applications par défaut nommé « DefaultAppPool », qui s’exécute ASP.NET v2.1 en mode intégré. Déplacez l’application vers « Classic .NET AppPool » pour qu’elle s’exécute en mode classique ASP.NET v2.1 ou un autre pool d’applications de votre choix.
2. Configurez le pool d’applications dans lequel l’application s’exécute pour utiliser la version de ASP.NET souhaitée.
   Par défaut, tous les nouveaux pools d’applications sont configurés pour exécuter ASP.NET v2.1 en mode intégré.

IIS utilise des mappages de gestionnaires préconfigurés pour sélectionner automatiquement l’ensemble correct de mappages de gestionnaires (pour ASPNET_isapi.dll en mode Classique ou directement vers les types de gestionnaires managés en mode intégré) en fonction de la version CLR configurée et du mode d’intégration managé du pool d’applications. La configuration ASP.NET 2.0 installe ces mappages de gestionnaires au niveau du serveur.

Tirer parti du mode de ASP.NET intégré

Sur IIS, les applications ASP.NET s’exécutent en mode intégré par défaut. Toutefois, pour tirer parti des avantages fournis par une intégration plus étroite, vous devez apporter des modifications à la configuration de l’application. Vous pouvez également développer de nouveaux composants ASP.NET qui tirent parti du mode intégré pour fournir des fonctionnalités puissantes à votre application.

Activation des services ASP.NET pour tous les types de contenu

En mode intégré, les services fournis par ASP.NET modules sont disponibles pour les requêtes de tous les types de contenu. Toutefois, par défaut, les modules ASP.NET sont configurés pour s’exécuter uniquement pour les requêtes d’ASP.NET contenu pour la compatibilité descendante.

Pour ce faire, attachez une condition préalable managedHandler à chaque module ASP.NET dans la section de configuration au niveau du serveur :

<modules> 
     <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" 
             preCondition="managedHandler" />
     <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" 
             preCondition="managedHandler" />
    ...
</modules>

La condition préalable est une règle que le serveur évalue sur chaque requête pour déterminer si un module sera exécuté. La condition préalable de managedHandler est vraie uniquement pour les requêtes adressées aux types de contenu mappés à des gestionnaires ASP.NET.

Pour appliquer des fonctionnalités fournies par un module ASP.NET à toutes les requêtes, supprimez l’entrée du module, puis rajoutez-la sans condition préalable dans le fichier Web.config racine de l’application.

Pour activer ASP.NET l’authentification par formulaire pour l’ensemble de l’application, modifiez votre fichier Web.config comme suit :

<modules> 
    <remove name="FormsAuthentication" /> 
    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" /> 
    …
</modules>

Avec cette modification, le module FormsAuthentication s’exécute pour toutes les requêtes de votre application. Cela vous permet de protéger tout le contenu de l’application avec l’authentification par formulaire. Pour plus d’informations sur l’utilisation du mode intégré pour fournir l’authentification par formulaire pour tout le contenu de l’application, consultez La procédure pas à pasdu mode pipeline intégré.

Vous pouvez également utiliser un raccourci pour permettre à tous les modules managés (ASP.NET) de s’exécuter pour toutes les requêtes de votre application, quelle que soit la condition préalable « managedHandler ». Pour permettre à tous les modules managés de s’exécuter pour toutes les requêtes sans configurer chaque entrée de module pour supprimer la condition préalable « managedHandler », utilisez la propriété runAllManagedModulesForAllRequests dans la section <modules> :

<modules runAllManagedModulesForAllRequests="true" />

Lorsque vous utilisez ce paramètre, la condition préalable « managedHandler » n’a aucun effet et tous les modules managés s’exécutent pour toutes les requêtes.

Essayez d’activer d’autres modules ASP.NET à appliquer à l’ensemble de votre application. Par exemple, utilisez le module ASP.NET Cache de sortie pour générer des pages ASP de cache, ou utilisez l’autorisation d’URL et le Gestionnaire de rôles pour configurer les règles de contrôle d’accès pour vos photos. Vous pouvez également développer votre propre module pour apporter la puissance de ASP.NET à l’ensemble de votre site web.

Création de services ASP.NET plus puissants

En mode intégré, les modules ASP.NET appliquent leurs services à tout le contenu. En outre, étant donné que les modules ASP.NET s’exécutent dans le pipeline de traitement des requêtes unifié en mode intégré, ils s’abonnent aux mêmes étapes de traitement des requêtes et effectuent les mêmes tâches que les modules serveur natifs. En même temps, les API ASP.NET restent largement identiques, avec quelques ajouts clés qui déverrouillent les fonctionnalités précédemment indisponibles.

Fidélité du runtime

En mode intégré, les ASP.NET étapes de traitement des requêtes exposées aux modules sont directement connectées aux étapes correspondantes du pipeline IIS. Le pipeline complet contient les étapes suivantes, qui sont exposées en tant qu’événements HttpApplication dans ASP.NET :

1. BeginRequest. Le traitement des requêtes démarre.
2. AuthenticateRequest. La requête est identifiée. Les modules d’authentification IIS et ASP.NET s’abonnent à cette étape pour effectuer l’authentification.
3. PostAuthenticateRequest.
4. AuthorizeRequest. La requête n’est pas autorisée. Les modules d’autorisation IIS et ASP.NET vérifient si l’utilisateur authentifié a accès à la ressource demandée.
5. PostAuthorizeRequest.
6. ResolveRequestCache. Les modules de cache vérifient si la réponse à cette requête existe dans le cache et la retourne au lieu de continuer avec le reste du chemin d’exécution. Les fonctionnalités ASP.NET du cache de sortie et du cache de sortie IIS s’exécutent toutes deux.
7. PostResolveRequestCache.
8. MapRequestHandler. Cette étape est interne dans ASP.NET et est utilisée pour déterminer le gestionnaire de requêtes.
9. PostMapRequestHandler.
10. AcquireRequestState. L’état nécessaire pour l’exécution de la requête est récupéré. ASP.NET modules d’état de session et de profil obtiennent leurs données.
11. PostAcquireRequestState.
12. PreExecuteRequestHandler. Toutes les tâches avant l’exécution du gestionnaire sont effectuées.
13. ExecuteRequestHandler. Le gestionnaire de requêtes s’exécute. Les pages ASPX, les pages ASP, les programmes CGI et les fichiers statiques sont servis.
14. PostExecuteRequestHandler
15. ReleaseRequestState. Les modifications de l’état de la requête sont enregistrées et l’état est nettoyé ici. Les modules d’état de session et de profil ASP.NET utilisent cette étape pour le nettoyage.
16. PostReleaseRequestState.
17. UpdateRequestCache. La réponse est stockée dans le cache pour une utilisation ultérieure. Les modules de cache de sortie ASP.NET et IIS s’exécutent pour enregistrer la réponse dans leurs caches.
18. PostUpdateRequestCache.
19. LogRequest. Cette étape enregistre les résultats de la requête et est garantie d’être exécutée même si des erreurs se produisent.
20. PostLogRequest.
21. EndRequest. Cette étape effectue tout nettoyage de la requête finale et est garanti pour s’exécuter même si des erreurs se produisent.

En utilisant les API ASP.NET familières, la possibilité d’exécuter dans les mêmes phases que les modules IIS rendent les tâches qui n’étaient accessibles qu’auparavant dans les filtres et extensions ISAPI natifs désormais possibles dans le code managé.

Par exemple, vous pouvez maintenant écrire des modules qui effectuent les opérations suivantes :

1. Interceptez la requête avant qu’un traitement ait eu lieu, par exemple réécriture des URL ou effectuez un filtrage de sécurité.
2. Remplacez les modes d’authentification intégrés.
3. Modifiez le contenu de la requête entrante, comme les en-têtes de requête.
4. Filtrez les réponses sortantes pour tous les types de contenu.

Consultez Développement d’un module IIS 7 et versions ultérieures avec .NET pour obtenir un bon exemple d’extension d’IIS avec un module d’authentification ASP.NET personnalisé.

API ASP.NET développées

Les API ASP.NET restent à compatibilité descendante avec les versions précédentes, ce qui permet aux modules existants de fonctionner dans IIS 7 et versions ultérieures sans modification, et de s’appliquer à tout le contenu de l’application sans modification du code.

Toutefois, les modules écrits pour le mode intégré IIS peuvent tirer parti de quelques API supplémentaires pour activer les scénarios de traitement des requêtes clés qui n’étaient pas disponibles précédemment.

La nouvelle collection HttpResponse.Headers permet aux modules d’inspecter et de manipuler les en-têtes de réponse générés par d’autres composants d’application. Par exemple, vous pouvez modifier l’en-tête Content-Type généré par une page ASP pour inviter une boîte de dialogue de téléchargement dans le navigateur. La collection Cookies sur la classe HttpResponse est également améliorée pour permettre la modification des cookies générés dans le cadre du traitement des requêtes, même s’ils ont été créés en dehors de ASP.NET.

La collection HttpRequest.Headers est activée en écriture, ce qui permet aux modules de manipuler les en-têtes de requête entrants. Utilisez cette option pour modifier le comportement d’autres composants serveur, par exemple, vous pouvez forcer une application localisée à répondre au client dans une autre langue en modifiant dynamiquement la valeur de l’en-tête Accept-Language.

Enfin, la collection HttpRequest.ServerVariables est désormais accessible en écriture, ce qui permet aux variables de serveur IIS d’être définies. Les modules ASP.NET utilisent cette fonctionnalité pour modifier les valeurs fournies par IIS et créer de nouvelles variables de serveur visibles par d’autres frameworks d’application, comme PHP.

Intégration au runtime

Outre les nouvelles API, le mode intégré permet aux fonctionnalités de ASP.NET existantes de fournir plus de valeur à votre application.

Les installations de suivi fournies par ASP.NET, y compris la classe System.Diagnostics.Trace et la fonctionnalité de suivi de page ASP.NET, émettent désormais des informations de trace dans le système de suivi IIS. Cela permet aux informations de trace générées pendant le traitement des requêtes par les composants IIS et ASP.NET d’être placés dans un fichier journal unique, ce qui facilite de meilleurs diagnostics des problèmes de serveur.

La fonctionnalité de filtrage des réponses ASP.NET, qui permet de modifier les réponses à l’aide d’une interface Stream avant d’accéder au client, est améliorée pour permettre le filtrage de contenu non-ASP.NET. Par conséquent, vous pouvez utiliser le filtrage ASP.NET sur tout le contenu du serveur ou installer de manière sélective le filtre uniquement pour les requêtes adressées au contenu que vous souhaitez traiter. Avec cette fonctionnalité, vous pouvez écrire des fonctionnalités de filtrage qui injectent ou censurent du contenu dans les réponses du site, que ce contenu provient d’une page ASPX ou d’un fichier statique.

Résumé

L’intégration ASP.NET dans IIS 7 et versions ultérieures déverrouille le plein potentiel de ASP.NET, ce qui permet aux développeurs de créer de puissants composants serveur avec la facilité et la richesse des ASP.NET et du .NET Framework. Pour en savoir plus sur l’utilisation du mode intégré ASP.NET pour les applications existantes, consultez Tirer parti du mode pipeline intégré. Pour plus d’informations sur la création de nouveaux composants ASP.NET pour étendre le serveur, consultez Développement d’un module IIS 7 et versions ultérieures avec .NET.