Partager via


Utilisation du suivi des demandes ayant échoué pour suivre les règles de réécriture

par Ruslan Yakushev

Le suivi des demandes ayant échoué (FRT) IIS 7.0 et versions ultérieures est un outil puissant pour résoudre les échecs de traitement des demandes. FRT peut être utilisé avec le module de réécriture d’URL pour suivre la façon dont les règles de réécriture ont été appliquées à l’URL de demande. Cette procédure pas à pas vous guide tout au long de l’utilisation de FRT pour résoudre les problèmes des règles de réécriture d’URL et les déboguer. Pour plus d’informations sur le suivi des demandes ayant échoué, consultez cet article.

Prérequis

Cette procédure pas à pas nécessite les prérequis suivants :

  1. IIS 7.0 ou version ultérieure avec ASP.NET et les services de rôle « Suivi » activés
  2. Réécriture de l’URL version Go Live installée

Configuration d’une page web de test

Pour illustrer le fonctionnement du module de réécriture d’URL, nous utilisons une page de test ASP.NET simple. Cette page lit les variables de serveur web et génère leurs valeurs dans le navigateur.

Copiez le code ASP.NET suivant et placez-le dans le dossier %SystemDrive%\inetpub\wwwroot\ dans un fichier appelé article.aspx :

<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>URL Rewrite Module Test</title>
</head>
<body>
      <h1>URL Rewrite Module Test Page</h1>
      <table>
            <tr>
                  <th>Server Variable</th>
                  <th>Value</th>
            </tr>
            <tr>
                  <td>Original URL: </td>
                  <td><%= Request.ServerVariables["HTTP_X_ORIGINAL_URL"] %></td>
            </tr>
            <tr>
                  <td>Final URL: </td>
                  <td><%= Request.ServerVariables["SCRIPT_NAME"] + "?" + Request.ServerVariables["QUERY_STRING"] %></td>
            </tr>
      </table>
</body>
</html>

Après avoir copié ce fichier, accédez à http://localhost/article.aspx et vérifiez que la page s’affiche correctement dans un navigateur.

Screenshot of accessing the article page through the web browser.

Configuration des règles de réécriture

Recherchez un fichier web.config dans le dossier %SystemDrive%\inetpub\wwwroot\ ou créez-en un s’il n’y en a pas. Ouvrez le fichier web.config et ajoutez la section suivante à l’intérieur de l’élément <system.webServer> :

<rewrite>
      <rules>
        <rule name="Fail bad requests">
          <match url="." />
          <conditions>
            <add input="{HTTP_HOST}" negate="true" pattern="localhost" />
          </conditions>
          <action type="AbortRequest" />
        </rule>
        <rule name="Rewrite to article.aspx">
          <match url="^article/([0-9]+)/([_0-9a-z-]+)" />
          <action type="Rewrite" url="article.aspx?id={R:1}&amp;title={R:2}" />
        </rule>
      </rules>
</rewrite>
  • La règle « Échec des demandes incorrectes » abandonne la connexion HTTP si l’en-tête de l’hôte de la requête HTTP ne correspond pas à « localhost »
  • La règle « Réécrire en article.aspx » réécrit les URL de ce format http://localhost/article/234/some-title en ce format http://localhost/article.aspx?id=234&title=some-title.

Vérifiez que les règles sont correctement configurées en ouvrant un navigateur et en envoyant la demande http://localhost/article/234/some-title. Si les règles ont été correctement configurées, vous devez voir la réponse suivante dans le navigateur :

Screenshot of the U R L Rewrite Module Test Page that displays the original U R L and the rewritten version.

Configurer le suivi des demandes ayant échoué

Activez maintenant le suivi des demandes ayant échoué pour un « site web par défaut » (consultez cet article pour des instructions pas à pas sur l’activation de FRT). Une fois que vous avez activé le suivi des demandes ayant échoué, nous créons une règle FRT pour les événements de suivi propres au module de réécriture d’URL.

Pour créer une règle FRT dans le Gestionnaire IIS, suivez ces étapes :

  1. Cliquez sur l’icône « Règles de suivi des demandes ayant échoué » pour accéder à la liste des règles FRT.
    Screenshot of the Default Web Site Home pane with Failed Request Tracing Rules selected.
  2. Cliquez sur l’action « Ajouter... » pour afficher l’Assistant Création de règle FRT.Screenshot of the Add Failed Request Tracing Rule dialog with All content (asterisk) selected.
  3. Dans la première page de l’Assistant, choisissez « Tout le contenu (*) »
  4. Cliquez sur « Suivant » et spécifiez le ou les codes d’état « 200-399 »
    Screenshot of setting the status codes to the value of 200 dash 399.
  5. Cliquez sur Suivant, puis décochez tous les fournisseurs de trace à l’exception de « Serveur WWW », puis décochez toutes les zones de fournisseur, à l’exception de « Réécrire »Screenshot of setting Providers to only W W W Server and Areas to only Rewrite.
  6. Cliquez sur Terminer pour enregistrer la règle FRT.

Si le suivi des demandes ayant échoué a été installé après le module de réécriture d’URL, la zone « Réécrire » dans les fournisseurs de trace peut ne pas être disponible. Si vous ne voyez pas la zone « Réécrire » ici, accédez à Ajouter/Supprimer des programmes, puis exécutez le programme d’installation du module de réécriture d’URL en mode de réparation.

Analyse du fichier journal du suivi des demandes ayant échoué

Après la création de la règle FRT, envoyez une demande à http://localhost/article/234/some-title. Cela crée une connexion FRT %SystemDrive%\inetpub\Logs\FailedReqLogFiles\. Vous pouvez ouvrir ce journal dans Internet Explorer et l’afficher sous forme de document HTML facilement navigable. Voici un exemple d’événements propres à la réécriture d’URL qui se trouvent dans le fichier journal de trace :

Screenshot of accessing an F R T log using a web browser. The log shows the list of rewrite rules and their rewrite logic.

Ces événements montrent comment les règles de réécriture ont été évaluées et comment l’URL demandée a été modifiée par le module de réécriture. Examinons quelques-uns des événements pour mieux comprendre la logique d’évaluation des règles :

URL_REWRITE_START : cet événement indique le début des événements de réécriture d’URL. Les propriétés d’événement fournissent les informations suivantes :

  • La chaîne d’URL d’entrée est « /article/234/some-title ».
  • Il n’y a pas de chaîne de requête.
  • Scope="Distributed" indique que les règles sont locales (autrement dit, les règles sont définies dans le fichier Web.config du site) et non globales (c’est-à-dire définies au niveau du serveur).

RULE_EVALUATION_START : cet événement indique le début de la logique d’évaluation des règles. Les propriétés d’événement fournissent les informations suivantes :

  • La règle utilise des expressions régulières pour la syntaxe de modèle (patternSyntax="ECMAScript")
  • Les règles suivantes sont évaluées (StopProcessing = "false")
  • La règle est définie au niveau de la racine du site (RelativePath = "/")

PATTERN_MATCH : cet événement fournit des informations sur la façon dont l’URL a été comparée au modèle de règle. Les propriétés d’événement fournissent les informations suivantes :

  • Le modèle de règle est « . » (autrement dit, correspond à n’importe quel caractère)
  • L’URL d’entrée correspond au modèle

CONDITIONS_EVALUATION_START : comme l’URL d’entrée correspond au modèle, l’évaluation des conditions démarre

CONDITION_EVALUATION : cet événement fournit les informations suivantes :

  • La valeur de HTTP_HOST est « localhost » et correspond au modèle
  • Comme la négation de la condition a été spécifiée dans la règle (c.-à-d. Negated="true") l’évaluation de la condition n’a pas réussi.

CONDITIONS_EVALUATION_END : cet événement montre que l’évaluation des conditions pour cette règle n’a pas réussi

RULE_EVALUATION_END : cet événement indique que la règle n’a pas modifié l’URL (Succeeded="false"). C’est parce que l’évaluation de la condition de règle a échoué.

RULE_EVALUATION_START : cet événement montre que la chaîne d’URL a été passée à la deuxième règle

PATTERN_MATCH : cet événement fournit des informations sur la façon dont l’URL a été comparée au modèle de règle. Les propriétés d’événement nous indiquent que :

  • Le modèle de règle est : « ^article/([0-9]+)/([0-9a-z]+) »
  • L’URL d’entrée correspond au modèle

REWRITE_ACTION : cet événement indique que l’évaluation de la règle a réussi et que l’URL a été réécrite en « /article.aspx » avec la chaîne de requête « id=234&title=some-title »

Résumé

Les événements propres à la réécriture d’URL journalisés par FRT fournissent des informations très détaillées qui peuvent être utilisées pour la résolution des problèmes et le débogage des règles de réécriture d’URL, ainsi que simplement pour comprendre comment la logique d’évaluation des règles est appliquée à une chaîne d’URL.