Référence de configuration du module de réécriture d’URL 2.0

Article
04/12/2024

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

Cet article fournit une vue d’ensemble de la fonctionnalité de réécriture d’URL 2.0 et explique les nouveaux concepts de configuration utilisés dans cette version. Pour plus d’informations sur la configuration du module de réécriture d’URL 1.1, reportez-vous à la référence de configuration du module de réécriture d’URL.

Table du contenu

Vue d’ensemble des fonctionnalités

Le module de réécriture d’URL Microsoft 2.0 pour IIS est une version incrémentielle qui inclut toutes les fonctionnalités de la version 1.1 et ajoute la prise en charge des en-têtes de réponse et de la réécriture de contenu. Le module applique des expressions régulières ou des modèles génériques carte à la réponse HTTP pour localiser et remplacer les parties de contenu en fonction de la logique de réécriture exprimée par des règles de réécriture sortante. Plus précisément, le module peut être utilisé pour :

Remplacez les URL générées par une application web dans le code HTML de réponse par un équivalent convivial et convivial du moteur de recherche.
Modifier les liens dans le balisage HTML généré par une application web derrière un proxy inverse.
Modifiez les en-têtes HTTP existants et définissez de nouveaux en-têtes HTTP de réponse.
Corrigez le contenu de toute réponse HTTP, notamment JavaScript, CSS, RSS, etc.

Avertissement

Dans de nombreux autres cas, quand les en-têtes de réponse ou le contenu de la réponse sont modifiés par une règle de réécriture sortante, des précautions supplémentaires doivent être prises pour vérifier que le texte inséré dans la réponse ne contient aucun code exécutable côté client, ce qui peut entraîner des vulnérabilités de script intersites. Cela est particulièrement important quand la règle de réécriture utilise des données non approuvées, comme des en-têtes HTTP ou la chaîne de requête, pour générer la chaîne à insérer dans la réponse HTTP. Dans ce cas, la chaîne de remplacement doit être encodée au format HTML à l’aide de la fonction HtmlEncode , par exemple :

<action type="Rewrite" value="{HtmlEncode:{HTTP_REFERER}}" />

Vue d’ensemble des règles de trafic sortant

Le concept de configuration principal utilisé pour la réécriture de réponse est le concept d’une règle de trafic sortant. Une règle de trafic sortant est utilisée pour exprimer la logique de la comparaison ou de la correspondance avec le contenu de la réponse et de ce qu’il faut faire si la comparaison a réussi.

Conceptuellement, une règle de trafic sortant se compose des éléments suivants :

Pré-condition : la pré-condition facultative est utilisée pour case activée les métadonnées de la requête avant le début de l’évaluation des règles. La pré-condition peut se composer de plusieurs case activée conditionnelles par rapport aux métadonnées de la demande et peut être utilisée pour filtrer les réponses qui ne doivent pas être réécrites, par exemple des images ou des fichiers vidéo.
Filtres d’étiquettes : les filtres d’étiquettes sont utilisés pour affiner la recherche dans la réponse à un ensemble de balises connues ou personnalisées. Avec les filtres d’étiquettes, seul le contenu des balises spécifiées est mis en correspondance avec le modèle de règle, par opposition à la mise en correspondance de l’intégralité du contenu de réponse par rapport au modèle.
Modèle : le modèle de règle est utilisé pour spécifier l’expression régulière ou un modèle générique carte qui sera utilisé pour la recherche dans le contenu de la réponse.
Conditions : la collection de conditions facultatives permet de spécifier des opérations logiques supplémentaires à effectuer si une correspondance de modèle a été trouvée dans le contenu de la réponse. Dans les conditions, vous pouvez case activée pour certaines valeurs d’en-têtes HTTP ou de variables serveur.
Action : l’action permet de spécifier ce qu’il faut faire si la correspondance de modèle a été trouvée et que toutes les conditions de règle ont été évaluées avec succès.

Exécution des règles

Le processus d’exécution de règles de trafic sortant diffère de celui utilisé pour les règles de trafic entrant. Le jeu de règles de trafic entrant n’est évalué qu’une seule fois par requête, car son entrée n’est qu’une seule chaîne d’URL de requête. L’ensemble de règles sortants peut être évalué plusieurs fois par réponse, car il est appliqué à plusieurs emplacements dans le contenu de la réponse HTTP. Par exemple, s’il existe un ensemble de règles comme indiqué ci-dessous :

Règle 1 : s’applique à une balise et <à <une> balise img>

Règle 2 : s’applique à <une> balise

et la réponse HTML contient ce balisage :

<a href="/default.aspx"><img src="/logo.jpg" />Home Page</a>

Ensuite, le module de réécriture d’URL 2.0 évalue la règle 1 par rapport à la chaîne « /default.aspx ». Si la règle a été exécutée avec succès, la sortie de la règle 1 est donnée à Rule2. Si la règle 2 a été exécutée avec succès, la sortie de la règle 2 est utilisée pour remplacer le contenu de l’attribut href dans une <> balise dans la réponse.

Après cette réécriture d’URL, le module 2.0 évalue Rule1 par rapport à la chaîne « /logo.jpg ». Si la règle a été exécutée avec succès, sa sortie sera utilisée pour remplacer le contenu de l’attribut src dans la <balise img> dans la réponse.

Héritage des règles

Si des règles sont définies sur plusieurs niveaux de configuration, le module de réécriture d’URL évalue l’ensemble de règles qui inclut des règles distribuées à partir des niveaux de configuration parent et des règles du niveau de configuration actuel. L’évaluation est effectuée dans un ordre parent-enfant, ce qui signifie que les règles parentes sont évaluées en premier et que les règles définies sur un dernier niveau enfant sont évaluées en dernier.

Configuration des règles de trafic sortant

Collection de conditions préalables

Les conditions préalables sont utilisées pour case activée si une règle doit être évaluée par rapport à un contenu de réponse. La collection de conditions préalables est définie comme une collection nommée dans <la section preConditions> et peut contenir une ou plusieurs case activée s de pré-condition. La règle de trafic sortant fait référence à la collection de conditions préalables par nom.

Une collection de conditions préalables a un attribut appelé logicalGrouping qui contrôle la façon dont les conditions sont évaluées. Une collection de conditions préalables prend la valeur true si :

Toutes les conditions préalables à l’intérieur ont été évaluées sur true, à condition que logicalGrouping="MatchAll » ait été utilisé.
Au moins une des conditions préalables a été évaluée à true, à condition que logicalGrouping="MatchAny » ait été utilisé.

Une pré-condition est définie en spécifiant les propriétés suivantes :

Chaîne d’entrée : entrée pré-condition spécifie l’élément à utiliser comme entrée pour l’évaluation de la condition. L’entrée de pré-condition est une chaîne arbitraire qui peut inclure des variables de serveur et des références back-references aux modèles de pré-condition antérieurs.
Modèle : le modèle de pré-condition peut être spécifié à l’aide de la syntaxe d’expression régulière ou de la syntaxe wild carte. Le type de modèle à utiliser dans une pré-condition dépend de la valeur de l’indicateur patternSyntax défini pour la collection de pré-condition.

En outre, le résultat de l’évaluation de la pré-condition peut être négation à l’aide de l’attribut de négation .

Exemple de pré-condition qui case activée si le type de contenu de réponse est texte/html :

<preConditions>
    <preCondition name="IsHTML">
        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
    </preCondition>
</preConditions>

Filtres d’étiquettes

Les filtres d’étiquettes sont utilisés pour affiner la recherche dans le contenu de la réponse à un ensemble de balises HTML connues ou personnalisées. Lorsqu’une règle de réécriture utilise ensuite des filtres d’étiquettes, au lieu de faire correspondre le modèle de règle à l’ensemble de la réponse, l’URL Rewrite Module 2.0 recherche des balises HTML répertoriées dans le filtre d’étiquettes de la règle, puis prend le contenu de l’attribut URL de cette balise et l’évalue par rapport au modèle de la règle. Les filtres de balise sont spécifiés dans l’attribut filterByTags de l’élément <de correspondance> d’une règle de trafic sortant. Par exemple :

<match filterByTags="A" pattern="^/(article\.aspx.*)" />

Si une réponse HTTP contient une balise d’ancrage telle que :

<a href="/article.aspx?id=1">link</a>

Ensuite, le modèle de règle de réécriture sera évalué par rapport à la chaîne : « /article.aspx ?id=1 ».

Balises prédéfinies

Le module de réécriture d’URL 2.0 inclut un ensemble de balises prédéfinies qui peuvent être utilisées avec des règles de trafic sortant. Le tableau ci-dessous répertorie toutes les balises prédéfinies et les attributs, dont les valeurs seront utilisées comme entrée pour le modèle de règle sortante :

Tag	Attributs
A	href
Zone	href
Base	href
Formulaire	action
Frame	src, longdesc
Head	profile
IFrame	src, longdesc
Img	src, longdesc, usemap
Input	src, usemap
Lien	href
Script	src

Balises personnalisées

Si la réécriture doit être effectuée dans un attribut d’une balise qui n’est pas incluse dans la collection de balises prédéfinies, une collection de balises personnalisée peut être utilisée pour spécifier le nom de la balise et l’attribut correspondant qui doit être réécrit. La collection de balises personnalisées est définie comme une collection nommée dans la <section customTags> . La règle sortante fait référence à une collection de balises personnalisées par nom.

L’exemple suivant montre une définition d’une collection de balises personnalisées :

<customTags>
    <tags name="My Tags">
        <tag name="item" attribute="src" />
        <tag name="element" attribute="src" />
    </tags>
</customTags>

Cette collection de balises personnalisées peut être référencée à partir d’une règle de trafic sortant, comme illustré dans l’exemple ci-dessous :

<match filterByTags="A, CustomTags" customTags="My Tags" pattern="^/(article\.aspx.*)" />

Modèle de règle

Un modèle de règle est utilisé pour spécifier la chaîne d’entrée de règle à laquelle doit correspondre la chaîne d’entrée de règle. L’entrée de règle diffère en fonction de la configuration de la règle :

Si la règle utilise des filtres d’étiquettes, le contenu de l’attribut de balise correspondante est passé en tant qu’entrée pour la correspondance de modèle.
Si la règle n’utilise pas de filtres d’étiquettes, le contenu de réponse entier est passé en tant qu’entrée pour la correspondance de modèle.

Le modèle est spécifié dans un <élément de correspondance> d’une règle de réécriture.

Correspondance complète des modèles de réponse

Lorsque l’attribut filterByTags n’est pas spécifié dans l’élément de correspondance de la règle, le modèle est appliqué à l’ensemble du contenu de la réponse. L’évaluation des modèles d’expression régulière sur l’ensemble du contenu de réponse est une opération intensive du processeur et peut affecter les performances de l’application web. Il existe plusieurs options pour réduire la surcharge de performances introduite par le modèle de réponse complet correspondant :

Utilisez la mise en cache du mode utilisateur IIS et définissez l’attribut rewriteBeforeCache de l’élément <outboundRules> sur true :
```
<outboundRules rewriteBeforeCache="true">
```
Notez que ce paramètre ne doit pas être utilisé si l’encodage de transfert en bloc est utilisé pour les réponses.
Utilisez l’attribut occurrences de l’élément match de la règle. Par exemple, lorsque vous utilisez une règle pour insérer un fragment HTML dans l’élément <head> et que cette règle a un modèle qui recherche la balise fermante - </head>, vous pouvez définir occurrences="1 ». Cela indique au module de réécriture d’arrêter la recherche dans le reste de la réponse après la découverte de la <balise /head> .
```
<match pattern="&lt;/head&gt;" occurrences="1" />
```

Syntaxe du modèle de règle

La syntaxe du modèle de règle peut être spécifiée à l’aide de l’attribut patternSyntax d’une règle. Cet attribut peut être défini sur l’une des options suivantes :

ECMAScript – Syntaxe d’expression régulière compatible AVEC ECMAScript (compatible ECMAScript standard). Il s’agit d’une option par défaut pour n’importe quelle règle. Voici un exemple de format de modèle : « ^([_0-9a-zA-Z-]+/) ? (wp-.*) »

Wild carte – Syntaxe Wild carte utilisée dans le module de redirection HTTP IIS. Il s’agit d’un exemple de modèle au format suivant : « /Scripts/*.js », où l’astérisque (« * ») signifie « mettre en correspondance n’importe quel nombre de caractères et les capturer dans une référence back-reference ». Notez que le type de modèle wild carte ne peut pas être utilisé lorsque la règle n’a pas de filtres d’étiquettes.

ExactMatch : la recherche de chaîne exacte est effectuée dans la chaîne d’entrée.

L’étendue de l’attribut patternSyntax est par règle, ce qui signifie qu’elle s’applique au modèle de la règle actuelle et à tous les modèles utilisés dans les conditions de cette règle.

Propriétés du modèle de règle

Le modèle peut être négation à l’aide de l’attribut de négation de l’élément <match> . Lorsque cet attribut est utilisé, l’action de règle est effectuée uniquement si la chaîne d’entrée ne correspond pas au modèle spécifié.

Par défaut, la correspondance de modèle non sensible à la casse est utilisée. Pour activer la sensibilité de la casse, vous pouvez utiliser l’attribut ignoreCase de l’élément <match> de la règle.

Conditions de la règle

Les conditions de règle permettent de définir une logique supplémentaire pour l’évaluation des règles, qui peut être basée sur des entrées autres qu’une seule chaîne d’entrée actuelle. Toute règle peut avoir zéro ou plusieurs conditions. Les conditions de règle sont évaluées après la réussite de la correspondance du modèle de règle.

Les conditions sont définies dans une <collection de conditions> d’une règle de réécriture. Cette collection a un attribut appelé logicalGrouping qui contrôle la façon dont les conditions sont évaluées. Si une règle a des conditions, l’action de règle est effectuée uniquement si le modèle de règle est mis en correspondance et :

Toutes les conditions ont été évaluées sur true, à condition que logicalGrouping="MatchAll » ait été utilisé.
Au moins une des conditions a été évaluée à true, à condition que logicalGrouping="MatchAny » ait été utilisé.

Une condition est définie en spécifiant les propriétés suivantes :

Chaîne d’entrée : l’entrée condition spécifie l’élément à utiliser comme entrée pour l’évaluation de la condition. L’entrée de condition est une chaîne arbitraire qui peut inclure des variables de serveur et des références back-references aux modèles de condition antérieurs et/ou aux modèles de règle.
Modèle : modèle à rechercher dans l’entrée de condition. Un modèle peut être spécifié à l’aide de la syntaxe d’expression régulière ou de la syntaxe wild carte. Le type de modèle à utiliser dans une condition dépend de la valeur de l’indicateur patternSyntax défini pour la règle à laquelle cette condition appartient. Ce type de condition a deux attributs connexes correspondant au modèle de contrôle :
- modèle : utilisez cet attribut pour spécifier le modèle réel.
- ignoreCase : utilisez cet attribut pour contrôler si les critères correspondants à la condition doivent être sensibles à la casse ou ne respectant pas la casse.

Action de règle

Une action de règle de réécriture est effectuée lorsque la chaîne d’entrée correspond au modèle de règle et que l’évaluation de la condition a réussi (selon la configuration de la règle, toutes les conditions mises en correspondance ou une ou plusieurs des conditions mises en correspondance). Il existe deux types d’actions disponibles et l’attribut « type » de l’élément <de configuration d’action> peut être utilisé pour spécifier l’action que la règle doit effectuer. Les sections suivantes décrivent différents types d’actions et les options de configuration associées à des types d’actions spécifiques.

Réécrire l’action

L’action de réécriture remplace la chaîne d’entrée de règle actuelle par une chaîne de substitution. La chaîne de substitution est spécifiée dans l’attribut valeur de l’élément <d’action> de la règle. La chaîne de substitution est une chaîne de forme libre qui peut inclure les éléments suivants :

Références de retour aux modèles de condition et de règle. (Pour plus d’informations, consultez la section sur l’utilisation des références back-references.)
Variables de serveur. (Pour plus d’informations, consultez la section sur l’utilisation des variables de serveur.)

Aucune action

Aucune action n’est utilisée pour spécifier qu’aucune action ne doit être effectuée.

Accès aux en-têtes de réponse à partir de règles de réécriture

Le contenu d’un en-tête HTTP de réponse peut être obtenu à partir d’une règle de réécriture à l’aide de la même syntaxe que pour accéder aux variables de serveur, mais avec une convention d’affectation de noms spéciale. Si une variable serveur commence par « RESPONSE_ », elle stocke le contenu d’un en-tête de réponse HTTP dont le nom est déterminé à l’aide de la convention d’affectation de noms suivante :

Tous les symboles de trait de soulignement (« _ ») du nom sont convertis en symboles de tiret (« - »).
Le préfixe « RESPONSE_ » est supprimé

Par exemple, la pré-condition suivante est utilisée pour évaluer le contenu de l’en-tête de type de contenu :

<preCondition name="IsHTML">
    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
</preCondition>

Définition des en-têtes de requête et des variables serveur

Les règles de réécriture entrante dans le module de réécriture d’URL 2.0 peuvent être utilisées pour définir des en-têtes de requête et des variables serveur.

Liste des variables serveur autorisées

Les règles de réécriture globale peuvent être utilisées pour définir les en-têtes de requête et les variables de serveur, ainsi que pour remplacer toutes les variables existantes. Les règles de réécriture distribuée peuvent uniquement définir/remplacer les en-têtes de requête et les variables serveur définies dans la liste autorisée pour les variables <de serveur allowedServerVariables>. Si une règle de réécriture distribuée tente de définir une variable de serveur ou un en-tête HTTP qui n’est pas répertorié dans la <collection allowedServerVariables> , une erreur d’exécution est générée par le module de réécriture d’URL. La <collection allowedServerVariables> par défaut est stockée dans le fichier applicationHost.config et peut être modifiée uniquement par un administrateur de serveur IIS.

Utilisation de règles de réécriture entrante pour définir des en-têtes de requête et des variables de serveur

Un élément <de règle serverVariables> est utilisé pour définir une collection de variables de serveur et d’en-têtes http à définir. Celles-ci ne seront définies que si le modèle de règle a été mis en correspondance et que l’évaluation de la condition a réussi (selon la configuration de la règle, toutes les conditions mises en correspondance ou une ou plusieurs des conditions mises en correspondance). Chaque élément de la <collection serverVariables> se compose des éléments suivants :

Nom : spécifie le nom de la variable de serveur à définir.
Valeur : spécifie la valeur de la variable de serveur. La valeur est une chaîne de forme libre qui peut inclure :
- Références de retour aux modèles de condition et de règle. (Pour plus d’informations, consultez la section sur l’utilisation des références back-references.)
- Variables de serveur. (Pour plus d’informations, consultez la section sur l’utilisation des variables de serveur.)
Indicateur de remplacement : spécifie s’il faut remplacer la valeur de la variable de serveur s’il existe déjà. Par défaut, la fonctionnalité de remplacement est activée.

L’exemple de règle suivant réécrit l’URL demandée et définit également la variable de serveur avec le nom X_REQUESTED_URL_PATH :

<rule name="Rewrite to index.php" stopProcessing="true">
    <match url="(.*)\.htm$" />
    <serverVariables>
        <set name="X_REQUESTED_URL_PATH" value="{R:1}" />
    </serverVariables>
    <action type="Rewrite" url="index.php?path={R:1}" />
</rule>

Remarque : pour que l’exemple ci-dessus fonctionne, il est nécessaire d’ajouter X_REQUESTED_URL_PATH à la <collection allowedServerVariables> :

<rewrite>
    <allowedServerVariables>
        <add name="X_REQUESTED_URL_PATH" />
    </allowedServerVariables>
</rewrite>

Remarque sur les en-têtes de requête

Les en-têtes de requête sont définis à l’aide du même mécanisme que pour les variables de serveur, mais avec une convention d’affectation de noms spéciale. Si un nom de variable serveur dans la <collection serverVariables> commence par « HTTP_ », un en-tête de requête HTTP est défini conformément à la convention d’affectation de noms suivante :

Tous les symboles de trait de soulignement (« _ ») du nom sont convertis en symboles de tiret (« - »).
Toutes les lettres sont converties en minuscules.
Le préfixe « HTTP_ » est supprimé

Par exemple, la configuration suivante est utilisée pour définir l’en-tête x-original-host personnalisé sur la demande :

<set name="HTTP_X_ORIGINAL_HOST" value="{HTTP_HOST}" />

Définition des en-têtes de réponse

Les règles de réécriture sortante dans le module de réécriture d’URL 2.0 peuvent être utilisées pour définir des en-têtes HTTP de réponse nouveaux ou modifiés existants. Les en-têtes HTTP de réponse sont accessibles dans les règles de trafic sortant à l’aide de la même syntaxe que pour les variables de serveur et à l’aide de la convention d’affectation de noms, comme décrit dans l’accès aux en-têtes de réponse à partir de règles de réécriture.

Si l’attribut serverVariable de l’élément <de correspondance> d’une règle de réécriture sortante a une valeur, il indique que cette règle de réécriture fonctionne sur le contenu de l’en-tête de réponse correspondant. Par exemple, la règle suivante définit l’en-tête de réponse « x-custom-header » :

<outboundRules>
    <rule name="Set Custom Header">
        <match serverVariable="RESPONSE_X_Custom_Header" pattern="^$" />
        <action type="Rewrite" value="Something" />
    </rule>
</outboundRules>

Le modèle de la règle de réécriture est appliqué au contenu de l’en-tête de réponse spécifié et si le modèle de la règle et les conditions facultatives évaluent correctement la valeur de cet en-tête de réponse.

Les modèles d’expression régulière et l’accès facile aux en-têtes de requête et de réponse existants au sein d’une règle de réécriture offrent une grande flexibilité lors de la définition d’une logique pour la réécriture d’en-têtes HTTP de réponse. Par exemple, la règle de réécriture suivante peut être utilisée pour modifier le contenu de l’en-tête Location dans les réponses de redirection :

<outboundRules>
    <!-- This rule changes the domain in the HTTP location header for redirection responses -->
    <rule name="Change Location Header">
        <match serverVariable="RESPONSE_LOCATION" pattern="^http://[^/]+/(.*)" />
        <conditions>
            <add input="{RESPONSE_STATUS}" pattern="^301" />
        </conditions>
        <action type="Rewrite" value="http://{HTTP_HOST}/{R:1}"/>
    </rule>
</outboundRules>

Utilisation de références back-references dans les règles de réécriture

Certaines parties des entrées de règles ou de conditions peuvent être capturées dans des références back-references. Ils peuvent ensuite être utilisés pour construire des URL de substitution dans des actions de règles ou pour construire des chaînes d’entrée pour les conditions de règle.

Les références back-references sont générées de différentes façons, selon le type de syntaxe de modèle utilisé pour la règle. Lorsque la syntaxe du modèle ECMAScript est utilisée, une référence back-reference peut être créée en plaçant des parenthèses autour de la partie du modèle qui doit capturer la référence back-reference. Par exemple, le modèle ([0-9]+)/([a-z]+).html capture 07 et l’article dans les références back-references de cette chaîne : 07/article.html. Lorsque la syntaxe de modèle « Wild carte » est utilisée, les références back-references sont toujours créées lorsqu’un symbole astérisque (*) est utilisé dans le modèle.

L’utilisation des références back-references est la même, quelle que soit la syntaxe de modèle utilisée pour les capturer. Les références back-references peuvent être utilisées dans les emplacements suivants dans les règles de réécriture :

Chaîne d’entrée de condition
Dans l’action de règle, en particulier :
- attribut url de réécriture et d’action de redirection dans les règles de trafic entrant
- attribut valeur de l’action réécrire dans les règles de trafic sortant
- statusLine et responseLine de l’action CustomResponse
Dans le paramètre clé du mappage de réécriture

Les références de retour aux modèles de condition sont identifiées par {C :N} où N est comprise entre 0 et 9 ; Les références back-references au modèle de règle sont identifiées par {R :N} où N est comprise entre 0 et 9. Notez que pour les deux types de références back-references, {R :0} et {C :0}, contiennent la chaîne correspondante.

Par exemple, dans ce modèle :

^(www\.)(.*)$

Pour la chaîne : www.foo.com les références back-references sont indexées comme suit :

{C:0} - www.foo.com
{C:1} - www.
{C:2} - foo.com

Suivi des groupes de capture entre les conditions

Par défaut, dans une action de règle, vous pouvez utiliser les références back-references au modèle de règle et à la dernière condition correspondante de cette règle. Par exemple, dans cette règle :

<rule name="Back-references with trackAllCaptures set to false">
 <match url="^article\.aspx" >
 <conditions>
    <add input="{QUERY_STRING}" pattern="p1=([0-9]+)" />
    <add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />  
 </conditions>
 <action type="Rewrite" url="article.aspx/{C:1}" /> <!-- rewrite action uses back-references to the last matched condition -->
</rule>

La référence back-reference {C :1} contient toujours la valeur du groupe de captures à partir de la deuxième condition, qui sera la valeur du paramètre de chaîne de requête p2. La valeur de p1 ne sera pas disponible en tant que référence back-reference.

Dans le module de réécriture d’URL 2.0, il est possible de modifier la façon dont les groupes de capture sont indexés. L’activation du paramètre trackAllCaptures sur la <collection de conditions> rend les groupes de captures sous forme de toutes les conditions correspondantes à mettre à disposition via les références back-references. Par exemple, dans cette règle :

<rule name="Back-references with trackAllCaptures set to true">
 <match url="^article\.aspx" >
 <conditions trackAllCaptures="true">
    <add input="{QUERY_STRING}" pattern="p1=([0-9]+)" />
    <add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />  
 </conditions>
 <action type="Rewrite" url="article.aspx/{C:1}/{C:2}" /> <!-- rewrite action uses back-references to both conditions -->
</rule>

La référence back-reference {C :1} contiendra la valeur du groupe de captures à partir de la première condition, et la référence back-reference {C :2} contiendra la valeur du groupe de captures à partir de la deuxième condition.

Lorsque trackAllCaptures a la valeur true, les références back-references de capture de condition sont identifiées par {C :N}, où N est compris entre 0 et le nombre total de groupes de capture dans toutes les conditions de la règle. {C :0} contient la chaîne correspondante entière de la première condition correspondante. Par exemple, pour ces deux conditions :

<conditions trackAllCaptures="true">
    <add input="{REQUEST_URI}" pattern="^/([a-zA-Z]+)/([0-9]+)/$" />
    <add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />  
 </conditions>

Si {REQUEST_URI} contient « /article/23/ » et {QUERY_STRING} contient « p1=123&p2=abc », les références back-references de condition sont indexées comme suit :

{C :0} - « /article/23/ »
{C :1} - « article »
{C :2} - « 23 »
{C :3} - « abc »

Journalisation des URL réécrites dans les journaux IIS

Une règle de réécriture entrante distribuée peut être configurée pour journaliser les URL réécrites dans les fichiers journaux IIS, au lieu de journaliser les URL d’origine demandées par le client HTTP. Pour activer la journalisation des URL réécrites, utilisez l’attribut logRewrittenUrl de l’élément d’action> de <la règle, par exemple :

<rule name="set server variables">
    <match url="^article/(\d+)$" />
    <action type="Rewrite" url="article.aspx?id={R:1}" logRewrittenUrl="true" />
</rule>

Partager via