Utilisation du module de réécriture d’URL 2.0

Présentation

Cette section de la documentation s’applique à la réécriture d’URL 2.0 pour IIS 7.

La réécriture d’URL 2.0 pour IIS 7 et versions ultérieures est une version incrémentielle qui inclut toutes les fonctionnalités de la version 1.1 et ajoute la prise en charge de l’extensibilité .NET et de la réécriture de réponse sortante. Plus précisément, il peut être utilisé pour :

Implémenter une logique de réécriture complexe à l’aide de fournisseurs de réécriture écrits dans .NET
Remplacez les URL générées par une application web dans le code HTML de réponse par un équivalent convivial pour les utilisateurs et les moteurs de recherche.
Modifiez les liens dans le balisage HTML généré par une application web derrière un proxy inverse.
Corrigez le contenu d’une réponse HTTP à l’aide de la correspondance de modèle d’expression régulière.
Modifiez les en-têtes de requête et de réponse HTTP et les variables de serveur IIS.

Fonctionnalités

La réécriture d’URL 2.0 inclut les fonctionnalités clés suivantes :

Fournisseurs de réécriture personnalisés (nouveautés de RTW). Les fournisseurs de réécriture peuvent être utilisés lorsqu’une logique de réécriture d’URL ne peut pas être exprimée en termes de modèles d’expression régulière ou lorsqu’il est nécessaire de prendre des décisions de réécriture en fonction des données stockées en dehors de web.config fichier (e.g. SQL base de données ou fichiers texte). Les fournisseurs de réécriture client peuvent être implémentés dans n’importe quel langage .NET.
Moteur de réécriture de réponse basée sur des règles. Les règles sortantes sont utilisées pour exprimer la logique permettant de déterminer les éléments avec lesquels comparer certaines parties de la réponse et ce qu'il faut faire si la comparaison réussit. Les administrateurs de serveur web et de site peuvent utiliser des règles de trafic sortant pour définir une logique de réécriture de réponse complexe.
Réécriture dans le contenu de balises HTML spécifiques. Au lieu d’analyser l’intégralité de la réponse pour une correspondance particulière, la règle peut être configurée pour regarder uniquement à l’intérieur de certaines balises HTML, telles qu’une<>, <img>, etc. De cette façon, le modèle est considérablement simplifié et le processus d’application de la règle au contenu est beaucoup plus rapide que d’appliquer le modèle à l’ensemble de la réponse.
Conditions préalables pour les règles de trafic sortant. L’application de règles de réécriture à chaque réponse est une opération coûteuse et n’est pas nécessaire dans la majorité des cas. Les conditions préalables sont utilisées pour vérifier les métadonnées de réponse pour déterminer si l’évaluation des règles sortantes doit être appliquée.
Réécriture des variables de serveur et des en-têtes de requête HTTP. Diverses variables de serveur IIS et en-têtes de requête HTTP peuvent être définis à l’aide de règles de réécriture.
Réécriture d’en-têtes de réponse HTTP. Les règles de réécriture sortante peuvent être utilisées pour modifier les en-têtes de réponse HTTP existants ou pour en définir de nouveaux.
Liste d'autorisation pour les variables de serveur. Pour empêcher les règles de réécriture distribuées de modifier accidentellement ou délibérément des variables de serveur IIS susceptibles d’affecter la sécurité ou le comportement d’exécution d’une application web, les variables de serveur modifiables doivent maintenant être ajoutées explicitement à la liste verte.
Fonction HtmlEncode. La réécriture sortante peut souvent utiliser des données non approuvées (par exemple, une chaîne de requête ou des en-têtes HTTP) pour générer une chaîne de remplacement à insérer dans la réponse HTTP. Dans ces cas, la fonction HtmlEncode doit être utilisée pour empêcher l’insertion de scripts côté client dans la réponse, ce qui peut entraîner une vulnérabilité de script intersites.
Suivi des groupes de capture entre les conditions de règle. La logique de référence des conditions dans la réécriture d’URL 1.1 a fonctionné uniquement par rapport aux dernières conditions correspondantes. Dans la version v2, il est possible de configurer la logique de "back-reference" pour qu'elle fonctionne avec toutes les conditions correspondantes.
Modèles de règle pour l’optimisation du moteur de recherche (nouveautés de RTW). Trois nouveaux modèles de règle facilitent la création de règles de redirection qui appliquent l’utilisation des URL canoniques pour les pages web de votre site.
Modèle de règle de proxy inverse (nouveau dans RTW). Ce modèle peut être utilisé pour générer très rapidement des règles de réécriture entrante et sortante qui implémentent la configuration du proxy inverse.
Journalisation des URL réécrites. Les règles de réécriture peuvent être configurées pour consigner l’URL réécrite dans les journaux IIS W3C, par opposition à la journalisation d’une URL demandée à l’origine.
Interface utilisateur mise à jour dans le Gestionnaire IIS. L’interface utilisateur a été considérablement améliorée pour mieux représenter la configuration du module et simplifier ces tâches courantes, telles que la configuration des règles de réécriture et des conditions de réécriture.

Installation du module

Téléchargez l’URL Rewrite 2.0 à l’aide des liens sur la page d’accueil du module à l’adresse https://www.iis.net/extensions/urlrewrite

Note

Si une version précédente de la réécriture d’URL, telle que v1.0 et v1.1, est déjà installée, elle est déjà mise à niveau vers la version 2.0
Si une version RC de la réécriture d’URL 2.0 est déjà installée, elle est mise à niveau vers la version RTW.

Problèmes connus

La réécriture de réponse ne fonctionne pas avec la compression statique. Vous devez désactiver la compression statique IIS afin d’utiliser la réécriture de réponse.
Les règles de trafic sortant ne sont pas appliquées aux réponses encodées de transfert en bloc si la réécritureBeforeCache est activée. Définissez rewriteBeforeCache sur false si vous devez réécrire les réponses qui sont encodées par transfert en bloc.

Installez les exemples d’extensibilité

Les exemples d’extensibilité de réécriture d’URL incluent les assemblys .NET et le code source implémentant ces fournisseurs :

DbProvider : ce fournisseur peut être utilisé pour récupérer des mappages de réécriture à partir d’une table de base de données SQL Server en exécutant une procédure stockée ;
FileMapProvider : ce fournisseur peut être utilisé pour récupérer les mappages de réécriture stockés dans un fichier texte ;
FileContainsProvider : ce fournisseur peut être utilisé pour vérifier si une chaîne dans un fichier texte est une sous-chaîne de la chaîne d’entrée du fournisseur.

Téléchargez les exemples d’extensibilité de réécriture d’URL à partir de MSDN Code Gallery.