Informations de référence sur la configuration du module de réécriture d’URL

  • Article

Auteur : Ruslan Yakushev

Cet article fournit une vue d’ensemble du module de réécriture d’URL et explique les concepts de configuration utilisés par le module.

Vue d’ensemble des fonctionnalités

Le module de réécriture d’URL réécrit les URL des URL pour des adresses conviviales, conviviales et conviviales pour les moteurs de recherche qui sont affichées aux utilisateurs ou dans les applications web. La réécriture d’URL utilise des règles définies pour évaluer, puis mapper l’URL de requête à l’adresse définie dans la règle avant qu’elle ne soit traitée par un serveur web IIS. Vous pouvez définir une logique de réécriture d’URL qui inclut des expressions régulières et des expressions génériques carte et des règles peuvent être appliquées en fonction de l’URL de requête, des en-têtes HTTP et des variables de serveur. Bien que l’objectif principal du module soit de réécrire des URL de requête vers des URL plus conviviales, vous pouvez également utiliser le module pour définir des règles qui effectuent des redirections, envoyer des réponses personnalisées ou abandonner des demandes.

Vue d’ensemble des règles de réécriture

Une règle de réécriture définit la logique de la comparaison ou de la correspondance avec l’URL de la demande et de ce qu’il faut faire si la comparaison réussit.

Les règles de réécriture se composent des parties suivantes :

  • 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 utilisé pour faire correspondre les chaînes d’URL.
  • Conditions : la collection de conditions facultatives est utilisée pour spécifier des opérations logiques supplémentaires à effectuer si une chaîne d’URL correspond au modèle de règle. Dans les conditions, vous pouvez case activée pour certaines valeurs d’en-têtes HTTP ou de variables de serveur, ou vérifier si l’URL demandée correspond à un fichier ou un répertoire sur un système de fichiers physique.
  • Action : l’action est utilisée pour spécifier ce qu’il faut faire si la chaîne d’URL correspond au modèle de règle et que toutes les conditions de règle sont remplies.

Réécrire l’étendue des règles

Les règles de réécriture peuvent être définies dans deux collections différentes :

  • <globalRules> : les règles de cette collection peuvent être définies uniquement au niveau du serveur. Les règles globales sont utilisées pour définir la logique de réécriture d’URL à l’échelle du serveur. Ces règles sont définies dans le fichier ApplicationHost.config et ne peuvent pas être remplacées ou désactivées sur des niveaux de configuration inférieurs. Les règles globales fonctionnent toujours sur le chemin d’accès de l’URL absolue (autrement dit, l’URI demandé sans le nom du serveur). Ces règles sont évaluées tôt dans le pipeline de traitement des demandes IIS (événement PreBeginRequest ).
  • <rules> : les règles de cette collection sont appelées règles distribuées et peuvent être définies à n’importe quel niveau dans la hiérarchie de configuration. Les règles de réécriture distribuée sont utilisées pour définir une logique de réécriture d’URL spécifique à une étendue de configuration particulière. Ce type de règle peut être ajouté à n’importe quel niveau de configuration à l’aide de fichiers Web.config ou à l’aide <location> de balises dans Les fichiers ApplicationHost.config ou Web.config. Les règles distribuées fonctionnent sur le chemin d’URL, par rapport à l’emplacement du fichier Web.config où elles sont définies. Dans les cas où les règles distribuées sont définies à l’intérieur d’une <location> balise, elles fonctionnent sur le chemin d’URL, par rapport au chemin spécifié pour cette <location> balise. Ces règles sont évaluées sur l’événement BeginRequest dans le pipeline IIS.

Évaluation des règles

Chaque niveau de configuration dans IIS peut avoir zéro ou plusieurs règles de réécriture définies. Les règles sont évaluées dans le même ordre dans lequel elles sont spécifiées. Le module de réécriture d’URL traite l’ensemble de règles à l’aide de l’algorithme suivant :

  1. Tout d’abord, l’URL est mise en correspondance avec le modèle d’une règle. S’il ne correspond pas, le module de réécriture d’URL arrête immédiatement le traitement de cette règle et passe à la règle suivante.
  2. Si un modèle correspond et qu’il n’existe aucune condition pour la règle, le module réécriture d’URL effectue l’action spécifiée pour cette règle, puis passe à la règle suivante, où elle utilise l’URL substituée comme entrée pour cette règle.
  3. Si un modèle correspond et qu’il existe des conditions pour la règle, le module de réécriture d’URL évalue les conditions. Si l’évaluation réussit, l’action de règle spécifiée est effectuée, puis l’URL réécrite est utilisée comme entrée dans la règle suivante.

Une règle peut avoir activé l’indicateur StopProcessing . Lorsque l’action de règle est effectuée (c’est-à-dire la règle mise en correspondance) et que cet indicateur est activé, cela signifie qu’aucune autre règle ne sera traitée et que la requête sera transmise au pipeline de requête IIS. Par défaut, cet indicateur est désactivé.

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 les règles dans l’ordre suivant :

  1. Évaluez toutes les règles globales.
  2. Évaluez un ensemble de règles qui inclut des règles distribuées à partir des niveaux de configuration parent ainsi que 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.

Conservation de l’URL d’origine

Le module de réécriture d’URL conserve le chemin d’accès d’URL demandé d’origine dans les variables de serveur suivantes :

  • HTTP_X_ORIGINAL_URL : cette variable de serveur contient l’URL d’origine au format décodé ;
  • UNENCODED_URL : cette variable de serveur contient l’URL d’origine exactement telle qu’elle a été demandée par un client Web, avec tout l’encodage d’origine conservé.

Accès aux parties d’URL à partir d’une règle de réécriture

Il est important de comprendre comment certaines parties de la chaîne d’URL sont accessibles à partir d’une règle de réécriture.

Pour une URL HTTP sous ce formulaire : http(s) ://<host> :<port>/<path> ?<Querystring>

  • Le <chemin d’accès> est mis en correspondance avec le modèle de la règle.
  • La <chaîne de> requête est disponible dans la variable de serveur appelée QUERY_STRING et est accessible à l’aide d’une condition dans une règle.
  • L’hôte <> est disponible dans la variable de serveur HTTP_HOST et est accessible à l’aide d’une condition dans une règle.
  • Le <port> est disponible dans la variable de serveur SERVER_PORT et est accessible à l’aide d’une condition dans une règle.
  • Les variables de serveur SERVER_PORT_SECURE et HTTPS peuvent être utilisées pour déterminer si une connexion sécurisée a été utilisée. Ces variables serveur sont accessibles à l’aide d’une condition au sein d’une règle.
  • La variable de serveur REQUEST_URI peut être utilisée pour accéder à l’intégralité du chemin d’URL demandé, y compris la chaîne de requête.

Par exemple, si une requête a été effectuée pour cette URL : http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3et qu’une règle de réécriture a été définie au niveau du site, puis :

  • Le modèle de règle obtient la chaîne content/default.aspx d’URL en tant qu’entrée.
  • La variable de serveur QUERY_STRING contient tabid=2&subtabid=3.
  • La variable de serveur HTTP_HOST contient www.mysite.com.
  • La variable de serveur SERVER_PORT contient 80.
  • La variable de serveur SERVER_PORT_SECURE contient 0 et HTTPS contient OFF.
  • La variable de serveur REQUEST_URI contient /content/default.aspx?tabid=2&subtabid=3.
  • La variable de serveur PATH_INFO contient /content/default.aspx.

Notez que la chaîne d’URL d’entrée passée à une règle distribuée est toujours relative à l’emplacement du fichier Web.config où la règle est définie. Par exemple, si une requête est effectuée pour http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3, et qu’une règle de réécriture est définie dans le répertoire /content , la règle obtient cette chaîne d’URL default.aspx en tant qu’entrée.

Réécrire la configuration des règles

Modèle de règle

Un modèle de règle de réécriture est utilisé pour spécifier un modèle auquel le chemin d’URL actuel est comparé. En cours, dans ce contexte, signifie que la valeur du chemin d’URL est appliquée à la règle. S’il existe des règles qui ont précédé la règle actuelle, elles ont peut-être mis en correspondance l’URL demandée d’origine et l’ont modifiée. La chaîne d’URL évaluée par rapport au modèle n’inclut pas la chaîne de requête. Pour inclure la chaîne de requête dans l’évaluation de la règle, vous pouvez utiliser la variable de serveur QUERY_STRING dans la condition de la règle. Pour plus d’informations, consultez « Utilisation de variables de serveur dans les règles de réécriture ».

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

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. Voici un exemple de modèle au format suivant : « /Scripts/*_in. ??? », où astérisque (« * ») signifie « mettre en correspondance n’importe quel nombre de caractères et les capturer dans une référence arrière » et « ? » signifie correspondre exactement à un caractère (aucune référence back-reference n’est créé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

Un modèle peut être supprimé à 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 l’URL actuelle 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 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’URL 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 comme vraies, à condition que logicalGrouping="MatchAll » ait été utilisé.
  • Au moins une des conditions a été évaluée comme vraie, à 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
  • Type de correspondance

L’entrée de 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.

Le type de correspondance peut être l’une des trois options suivantes :

  • IsFile : ce type de correspondance est utilisé pour déterminer si la chaîne d’entrée contient un chemin d’accès physique à un fichier sur un système de fichiers. Si aucune chaîne d’entrée de condition n’est spécifiée, le module de réécriture d’URL utilise le chemin d’accès physique du fichier demandé comme valeur par défaut pour l’entrée de condition. Ce type de correspondance ne peut être utilisé que pour les règles distribuées.

  • IsDirectory : ce type de correspondance est utilisé pour déterminer si la chaîne d’entrée contient un chemin d’accès physique à un répertoire sur un système de fichiers. Si aucune chaîne d’entrée de condition n’est spécifiée, le module de réécriture d’URL utilise le chemin d’accès physique du fichier demandé comme valeur par défaut pour l’entrée de condition. Ce type de correspondance ne peut être utilisé que pour les règles distribuées.

  • Modèle : ce type de correspondance est utilisé pour exprimer une condition dans laquelle une chaîne d’entrée arbitraire est mise en correspondance avec un modèle d’expression régulière. Un modèle de 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 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.

En outre, le résultat de l’évaluation de la condition peut être négation à l’aide de l’attribut de négation . Cela peut être utilisé pour spécifier une condition qui case activée si l’URL demandée n’est pas un fichier, comme dans l’exemple suivant :

<add input="{REQUEST_FILENAME}" matchType="isFile" negate="true">

Action de règle

Une action de règle de réécriture est effectuée lorsque l’URL actuelle 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 plusieurs types d’actions disponibles et l’attribut de type de l’élément <de configuration d’action> peut être utilisé pour spécifier l’action que la règle effectue. 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

Une action de réécriture remplace la chaîne d’URL actuelle par une chaîne de substitution. Une chaîne de substitution doit toujours spécifier le chemin d’URL (par exemple, contoso/test/default.aspx). Notez que les substitutions qui contiennent un chemin d’accès physique sur un système de fichiers (par exemple) C:\inetpub\wwwrootne sont pas prises en charge dans IIS.

Une action de réécriture comporte les options de configuration suivantes :

  • URL : il s’agit de la chaîne de substitution à utiliser lors de la réécriture de l’URL actuelle. L’URL de substitution est une valeur de chaîne 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.)

  • appendQueryString : spécifie si la chaîne de requête de l’URL actuelle est conservée pendant la substitution. Par défaut, si la valeur de l’indicateur appendQueryString n’est pas spécifiée, elle est supposée être TRUE. Cela signifie que la chaîne de requête de l’URL d’origine est ajoutée à l’URL remplacée.

Action de redirection

Une action de redirection indique au module de réécriture d’URL d’envoyer une réponse de redirection au client. Le code d’état de redirection (3xx) peut être spécifié en tant que paramètre pour cette action. Le champ Emplacement de la réponse contient la chaîne de substitution spécifiée dans la règle.

L’URL de substitution de la règle de redirection peut être spécifiée dans l’une des formes suivantes :

  • Chemin d’accès d’URL relative – contoso/test/default.aspx
  • URI absolu : https://example.com/contoso/test/default.aspx

L’utilisation d’une action de redirection implique qu’aucune règle ultérieure n’est évaluée pour l’URL actuelle après l’exécution de la redirection.

Une action de redirection comporte les options de configuration suivantes :

  • URL : utilise une chaîne de substitution comme URL de redirection. Une URL de substitution est une chaîne 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.)

  • appendQueryString : spécifie si la chaîne de requête de l’URL actuelle doit être conservée pendant la substitution. Par défaut, si l’indicateur AppendQueryString n’est pas spécifié, il est supposé être TRUE. Cela signifie que la chaîne de requête de l’URL d’origine est ajoutée à l’URL remplacée.

  • redirectType : spécifie le code d’état à utiliser pendant la redirection :

    • 301 – Permanent
    • 302 – Trouvé
    • 303 – Voir d’autres
    • 307 – Temporaire

Action CustomResponse

Une action CustomResponse entraîne la réponse du module de réécriture d’URL au client HTTP à l’aide d’un code d’état, d’un sous-code et d’une raison spécifiés par l’utilisateur. L’utilisation d’une action CustomResponse implique qu’aucune règle ultérieure n’est évaluée pour l’URL actuelle une fois cette action effectuée.

L’action CustomResponse a les options de configuration suivantes :

  • statusCode : spécifie le code d’état à utiliser en réponse au client.
  • subStatusCode : spécifie le code de sous-état à utiliser en réponse au client.
  • statusReason : spécifie l’expression de raison à utiliser avec le code d’état.
  • statusDescription : spécifie la description d’une ligne à placer dans le corps de la réponse.

Action AbortRequest

Une action AbortRequest entraîne la suppression du module de réécriture d’URL pour la requête actuelle. L’action n’a aucun paramètre. L’utilisation de cette action implique qu’aucune règle ultérieure n’est évaluée pour l’URL actuelle une fois cette action effectuée.

Aucune action

Une action None est utilisée pour spécifier qu’aucune action n’est effectuée.

Utilisation de variables de serveur dans les règles de réécriture

Les variables serveur fournissent des informations supplémentaires sur les requêtes HTTP actuelles. Vous pouvez utiliser ces informations pour prendre des décisions de réécriture ou pour composer l’URL réécrite. Les variables serveur peuvent être référencées dans les emplacements suivants dans les règles de réécriture :

  • Dans la chaîne d’entrée de condition

  • Dans les chaînes de substitution de règle, en particulier :

    • attribut url de réécriture et d’action de redirection
    • statusLine et responseLine d’une action CustomResponse

Les variables serveur peuvent être référencées à l’aide de la syntaxe {VARIABLE_NAME}. Par exemple, la condition suivante utilise la variable de serveur QUERY_STRING :

<add input="{QUERY_STRING}" pattern="id=([0-9]+)" />

Les variables serveur peuvent également être utilisées pour accéder aux en-têtes HTTP à partir de la requête actuelle. Tout en-tête HTTP fourni par la requête actuelle est représenté en tant que variable de serveur qui a un nom généré conformément à cette convention d’affectation de noms :

  1. Tous les symboles de tiret (« - ») dans le nom de l’en-tête HTTP sont convertis en symboles de soulignement (« _ »).
  2. Toutes les lettres du nom d’en-tête HTTP sont converties en majuscules.
  3. Le préfixe « HTTP_ » est ajouté au nom de l’en-tête.

Par exemple, pour accéder à l’en-tête HTTP « user-agent » à partir d’une règle de réécriture, vous pouvez utiliser la variable serveur {HTTP_USER_AGENT}.

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. Lorsqu’une syntaxe de 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 principales à partir de cette URL demandée : 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. Aucune référence back-references n’est créée quand « ? » est utilisé dans le modèle. Par exemple, le modèle */*.html capture contoso et teste dans les références back-references à partir de cette URL demandée : contoso/test.html.

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înes d’entrée de condition

  • Dans les actions de règle, en particulier :

    • attribut url de réécriture et d’action de redirection
    • statusLine et responseLine d’une action CustomResponse

  • Dans un paramètre clé de la carte 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 de retour aux modèles 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

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. Dans une chaîne d’entrée de condition, vous pouvez utiliser les références back-references au modèle de règle et à la condition précédemment correspondante.

L’exemple de règle suivant montre comment les références back-references sont créées et référencées :

<rule name="Rewrite subdomain">
 <match url="^(.+)" /> <!-- rule back-reference is captured here -->
 <conditions>
  <add input="{HTTP_HOST}" type="Pattern" pattern="^([^.]+)\.mysite\.com$" /> <!-- condition back-reference is captured here -->
 </conditions>
 <action type="Rewrite" url="{C:1}/{R:1}" /> <!-- rewrite action uses back-references to condition and to rule when rewriting the url -->
</rule>

Interaction avec la mise en cache de sortie IIS

Le module de réécriture d’URL contrôle le comportement du cache de sortie IIS afin de :

  1. Utilisez de manière optimale le mode noyau et la mise en cache de sortie du mode utilisateur des réponses pour les URL réécrites, ce qui améliore les performances de l’application web qui utilise le module de réécriture d’URL.
  2. Empêchez la mise en cache des réponses, lorsque la logique de mise en cache peut être violée en raison de la réécriture d’URL.

Le module contrôle la mise en cache de sortie en modifiant certaines propriétés de mise en cache ou en désactivant complètement la mise en cache. Le module ne peut pas activer la mise en cache de sortie si elle a été désactivée par la configuration IIS ou par tout autre module du pipeline IIS. La mise en cache de sortie est contrôlée comme suit :

  1. Le module définit toujours le paramètre de cache du mode utilisateur varieByHeader="HTTP_X_ORIGINAL_URL ». Cela garantit que lorsque la mise en cache du mode utilisateur est activée, le module prend en compte l’URL d’origine pour construire une clé pour l’entrée du cache.

  2. Si un jeu de règles de réécriture utilise des variables serveur avec des valeurs constantes tout au long de la durée du processus ou dérivées de l’URL demandée, l’ensemble de règles est considéré comme sécurisé pour la mise en cache de sortie. Cela signifie que le module de réécriture d’URL ne modifie pas la stratégie de mise en cache existante d’une autre façon que la définition de varyByHeader , comme décrit à l’étape 1.

    Les variables serveur suivantes, lorsqu’elles sont utilisées dans les règles de réécriture, n’entraînent aucun effet sur la stratégie de mise en cache de sortie :

    • « CACHE_URL »
    • « DOCUMENT_ROOT »
    • « HTTP_URL »
    • « HTTP_HOST »
    • « PATH_INFO »
    • « PATH_TRANSLATED »
    • « QUERY_STRING »
    • « REQUEST_FILENAME »
    • « REQUEST_URI »
    • « SCRIPT_FILENAME »
    • « SCRIPT_NAME »
    • « SCRIPT_TRANSLATED »
    • « UNENCODED_URL »
    • « URL »
    • « URL_PATH_INFO »
    • « "APP_POOL_ID »
    • « APPL_MD_PATH »
    • « APPL_PHYSICAL_PATH »
    • « GATEWAY_INTERFACE »
    • « SERVER_SOFTWARE »
    • « SSI_EXEC_DISABLED »

  3. Si un jeu de règles de réécriture utilise une variable de serveur non mentionnée dans la liste ci-dessus, l’ensemble de règles est considéré comme dangereux pour la mise en cache de sortie. Cela signifie que le module de réécriture d’URL désactive la mise en cache du mode noyau pour toutes les requêtes si les URL de requête ont été réécrites ou non. En outre, le module modifie la stratégie de mise en cache pour le cache en mode utilisateur en définissant la propriété de mise en cache varyByValue pour contenir la chaîne concaténée de toutes les valeurs de variables serveur utilisées dans l’ensemble de règles.

Fonctions de chaînes

Il existe trois fonctions de chaîne disponibles pour modifier les valeurs dans une action de règle de réécriture, ainsi que toutes les conditions :

  • ToLower : retourne la chaîne d’entrée convertie en minuscules.
  • UrlEncode : retourne la chaîne d’entrée convertie en format codé en URL. Cette fonction peut être utilisée si l’URL de substitution dans la règle de réécriture contient des caractères spéciaux (par exemple, des caractères non-ASCII ou non non sécurisés par URI).
  • UrlDecode : décode la chaîne d’entrée encodée par URL. Cette fonction peut être utilisée pour décoder une entrée de condition avant de la mettre en correspondance avec un modèle.

Les fonctions peuvent être appelées à l’aide de la syntaxe suivante :

{function_name:any_string}

Où « function_name » peut se trouver sur eof les éléments suivants : « ToLower », « UrlEncode », « UrlDecode ». « Any_string » peut être une chaîne littérale ou une chaîne créée à l’aide de variables de serveur ou de références back-references. Par exemple, les appels suivants sont des appels valides de fonctions de chaîne :

{ToLower:DEFAULT.HTM}
{UrlDecode:{REQUEST_URI}}
{UrlEncode:{R:1}.aspx?p=[résumé]}

Les fonctions de chaîne peuvent être utilisées dans les emplacements suivants dans les règles de réécriture :

  • Chaînes d’entrée de condition

  • Dans les chaînes de substitution de règle, en particulier :

    • attribut url des actions de réécriture et de redirection
    • attributs statusLine et responseLine d’une action CustomResponse

Exemple de règle qui utilise la fonction ToLower :

<rule name="Redirect to canonical url">
 <match url="^(.+)" /> <!-- rule back-reference is captured here -->
 <conditions>
  <!-- Check whether the requested domain is in canonical form -->
  <add input="{HTTP_HOST}" type="Pattern" pattern="^www\.mysite\.com$" negate="true" /> 
 </conditions>
 <!-- Redirect to canonical url and convert URL path to lowercase -->
 <action type="Redirect" url="http://www.mysite.com/{ToLower:{R:1}}" redirectType="Found" />
</rule>

Exemple de règle qui utilise la fonction UrlEncode :

<rules>
   <rule name="UrlEncode example" stopProcessing="true">
   <match url="resume" />
   <action type="Rewrite" url="default.aspx?name={UrlEncode:résumé}"/>
</rule>

Exemple de règle qui utilise la fonction UrlDecode :

<rules>
   <rule name="UrlDecode example">
      <match url="default.aspx" />
      <conditions>
         <add input="{UrlDecode:{QUERY_STRING}}" pattern="résumé" />
      </conditions>
      <action type="Rewrite" url="default.aspx?type=resume" />
   </rule>
</rules>

Tables de réécriture

Une carte de réécriture est une collection arbitraire de paires nom-valeur qui peuvent être utilisées dans les règles de réécriture pour générer l’URL de substitution pendant la réécriture. Les cartes de réécriture sont particulièrement utiles lorsque vous disposez d’un grand ensemble de règles de réécriture, qui utilisent toutes des chaînes statiques (c’est-à-dire qu’il n’existe aucuns critères spéciaux utilisés). Dans ce cas, au lieu de définir un grand ensemble de règles de réécriture simples, vous pouvez placer tous les mappages dans le mappage de réécriture en tant que clés et valeurs entre l’URL d’entrée et l’URL de substitution. Ensuite, pour rechercher l’URL de substitution en fonction de l’URL d’entrée, vous aurez une règle de réécriture qui référence le mappage de réécriture.

Un mappage de réécriture définit une collection nommée de chaînes de paires nom-valeur, comme dans l’exemple suivant :

<rewriteMap name="MyRewriteMap" defaultValue="">
  <add key="a.html" value="b.html" />
  <add key="c.aspx" value="d.aspx" />
  <add key="e.php" value="f.php" />
</rewriteMap>

Une carte de réécriture est identifiée de manière unique par son nom et peut contenir zéro ou plusieurs entrées clé-valeur. En outre, une carte de réécriture peut spécifier la valeur par défaut à utiliser lorsqu’une clé est introuvable. Ceci est contrôlé à l’aide de l’attribut defaultValue . Par défaut, une chaîne vide est utilisée comme valeur par défaut.

Il peut y avoir n’importe quel nombre de cartes de réécriture sur n’importe quel niveau de configuration, à l’exception du niveau fichier. Les mappages de réécriture se trouvent dans <l’élément de collection de réécriture Cartes>.

Les mappages de réécriture sont référencés dans une règle de réécriture à l’aide de la syntaxe suivante :

{RewriteMapName:Key}

Où le paramètre Key peut être n’importe quelle chaîne arbitraire et peut inclure des références back-references à des modèles de règle ou de condition. Par exemple, les utilisations suivantes sont valides d’une carte de réécriture :

{MyRewriteMap:contoso/{R:1}/test/{C:1}}
{MyRewriteMap:a.html}
{MyRewriteMap:{R:1}?{C:1}&contoso=test}

Une référence à une carte de réécriture est remplacée par la valeur recherchée à l’aide de la clé passée en tant que paramètre dans une référence de carte de réécriture. Si aucune clé n’a été trouvée, la valeur par défaut de ce mappage de réécriture est utilisée.

Une carte de réécriture peut être référencée dans les emplacements suivants dans les règles de réécriture :

  • Chaîne d’entrée de condition

  • Dans les chaînes de substitution de règle, en particulier :

    • attribut url des actions de réécriture et de redirection
    • statusLine et responseLine des actions CustomResponse

Exemple 1 : Avec une carte de réécriture définie comme suit :

<rewrite>
 <rewriteMaps>
  <rewriteMap name="StaticRewrites" defaultValue="">
    <add key="/diagnostics" value="/default.aspx?tabid=2&amp;subtabid=29" />
    <add key="/webcasts" value="/default.aspx?tabid=2&amp;subtabid=24" />
    <add key="/php" value="/default.aspx?tabid=7116" />
  </rewriteMap>
 </rewriteMaps>
</rewrite>

Et une règle de réécriture définie comme suit :

<rewrite>
 <rule name="Rewrite Rule">
  <match url=".*" />
  <conditions>
   <add input="{StaticRewrites:{REQUEST_URI}}" pattern="(.+)" />
  </conditions>
  <action type="Rewrite" url="{C:1}"/>
 </rule>
</rewrite>

L’URL demandée /diagnostic sera réécrite en tant que /default.aspx ?tabid=2&subtabid=29.
L’URL /webcasts demandée sera réécrite dans /default.aspx ?tabid=2&subtabid=24.
L’URL demandée /php sera réécrite dans /default.aspx ?tabid=7116.
L’URL demandée /default.aspx ne sera pas réécrite, car le mappage de réécriture ne contient pas d’élément avec key="/default.aspx » ; par conséquent, le mappage de réécriture retourne une chaîne vide qui ne correspond pas au modèle de condition, d’où l’action de règle ne sera pas effectuée.

Exemple 2 : Avec une carte de réécriture définie comme suit :

<rewrite>
 <rewriteMaps>
  <rewriteMap name="StaticRedirects" defaultValue="">
    <add key="/default.aspx?tabid=2&amp;subtabid=29" value="/diagnostics" />
    <add key="/default.aspx?tabid=2&amp;subtabid=24" value="/webcasts" />
    <add key="/default.aspx?tabid=7116" value="/php" />
  </rewriteMap>
 </rewriteMaps>
</rewrite>

Et une règle de réécriture définie comme suit :

<rewrite>
 <rule name="Redirect rule">
  <match url=".*" />
  <conditions>
   <add input="{StaticRedirects:{REQUEST_URI}}" pattern="(.+)" />
  </conditions>
  <action type="Redirect" url="http://www.contoso.com{C:1}" redirectType="Found" />
 </rule>
</rewrite>

L’URL demandée /default.aspx ?tabid=2&subtabid=29 sera redirigée vers http://www.contoso.com/diagnostics.
L’URL demandée /default.aspx ?tabid=2&subtabid=24 est redirigée vers http://www.contoso.com/webcasts.
L’URL demandée /default.aspx ?tabid=7116 sera redirigée vers http://www.contoso.com/php.
L’URL demandée /default.aspx n’est pas redirigée, car le mappage de réécriture ne contient pas d’élément avec key="/default.aspx » ; par conséquent, le mappage de réécriture retourne une chaîne vide qui ne correspond pas au modèle de condition, d’où l’action de règle ne sera pas effectuée.