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

Article
03/08/2024

Introduction

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

Le module de 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 de trafic sortant. Plus précisément, il peut être utilisé pour :

Implémenter une logique de réécriture complexe avec des fournisseurs de réécriture écrits en .NET
Remplacer les URL générées par une application web dans le code HTML de réponse par un équivalent plus convivial et compatible avec le moteur de recherche
Modifier les liens dans le balisage HTML généré par une application web derrière un proxy inverse.
Corriger le contenu d’une réponse HTTP en utilisant des critères spéciaux d’expression régulière.
Modifier les en-têtes de demande et de réponse HTTP, et les variables de serveur IIS.

Fonctionnalités

Le module de réécriture d’URL 2.0 comprend les fonctionnalités clés suivantes :

Fournisseurs de réécriture personnalisés (nouveau dans RTW). Les fournisseurs de réécriture peuvent être utilisés quand une logique de réécriture d’URL ne peut pas être exprimée en termes de modèles d’expression régulière ou quand il est nécessaire de prendre des décisions de réécriture basées sur des données stockées en dehors du fichier web.config (par ex., base de données SQL ou fichiers texte). Les fournisseurs de réécriture personnalisés 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 de trafic sortant sont utilisées pour exprimer la logique de ce à quoi comparer les parties de la réponse et de ce qu’il faut faire si la comparaison a réussi. 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 rechercher une correspondance en particulier, la règle peut être configurée pour regarder seulement dans certaines balises HTML, comme <a>, <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 l’application du 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 qui 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 la réponse afin de déterminer si l’évaluation des règles de trafic sortant doit être appliquée.
Réécriture des variables de serveur et des en-têtes de requête HTTP. Divers en-têtes de requête HTTP et variables de serveur IIS peuvent être définis avec des règles de réécriture.
Réécriture d’en-têtes de réponse HTTP. Les règles de réécriture de trafic sortant 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 d’autorisation.
Fonction HtmlEncode. La réécriture de trafic sortant 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 ce 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 dans les conditions de règle. La logique de rétro-référencement des conditions du module de réécriture d’URL 1.1 fonctionnait uniquement sur les dernières conditions correspondantes. Dans v2, vous pouvez configurer la logique de rétro-référencement pour toutes les conditions correspondantes.
Modèles de règle pour l’optimisation du référencement d’un site auprès d’un moteur de recherche (nouveau dans RTW). Trois nouveaux modèles de règle facilitent beaucoup 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 de trafic entrant et sortant qui implémentent la configuration du proxy inverse.
Journalisation des URL réécrites. Les règles de réécriture peuvent être configurées pour journaliser 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 les tâches courantes comme la configuration des règles de réécriture et des conditions de réécriture.

Installation du module

Téléchargez le modèle de réécriture d’URL 2.0 en utilisant les liens de la page d’accueil du module sur https://www.iis.net/extensions/urlrewrite

Remarque

Si une version précédente du module de réécriture d’URL, par exemple, v1.0 et v1.1, est déjà installée, elle est mise à niveau vers la version 2.0
Si une version RC du module de 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 pour pouvoir utiliser la réécriture de réponse.
Les règles de trafic sortant ne sont pas appliquées aux réponses encodées pour le transfert en bloc si rewriteBeforeCache est activé. Définissez rewriteBeforeCache sur false si vous devez réécrire des réponses encodées pour le transfert en bloc.

Installation des 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 dans 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 d’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.