Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Débogage de la réécriture d’url avec IIS

Poster un commentaire

La réécriture d’url fait partie de la vie de nombreux sites, mais il est parfois compliqué de comprendre pourquoi elle ne marche pas.

IIS fournit un outil « Failed Request Tracing » qui peut nous aider à comprendre ce qui se passe.

Cet été j’ai rédigé un tutoriel sur cet outil:

https://amethyste16.wordpress.com/2016/07/28/tracer-les-requetes-en-echec/

Mais je n’avais pas présenté de véritable exemple, alors en voici un.

Mise en place du projet de test

On juste besoin d’un site web sans grande imagination. Ce qu’il va afficher n’a pas d’importance car on va justement déboguer un cas où la redirection renvoie un 404.

Dans tous les cas on doit le déployer dans IIS.

Notre test

La réécriture d’url a été faite avec Url Rewrite. Dans IIS Manager il apparaît ainsi:

2016-12-07_09-56-53

Je vais rajouter une règle très caricaturale que l’on créée soit avec l’interface graphique:

2016-12-07_09-59-17

 

Soit en complétant le fichier web.config avec ceci dans <system.WebServer>:


<rewrite>
   <rules>
      <rule name="test fdlm" enabled="true">
         <match url="(.*)" />
         <conditions>
            <add input="{HTTP_HOST}" pattern="localhost" />
         </conditions>
         <action type="Rewrite" url="https://www.fdlm.com/{R:0}" logRewrittenUrl="true" />
      </rule>
   </rules>
</rewrite>

 

La règle remplace le nom du domaine localhost par fdlm.com qui est un domaine imaginaire. Comme prévu au lancement:

 

2016-12-07_10-05-45

Un 404 évidemment, et comme on l’observe pas des masses d’observations. Essayons d’en récupérer un peu plus.

Configurer le débogage

Il faut tout d’abord installer l’outil de tracing comme indiqué dans le tuto précédemment cité.

2016-12-07_10-08-44

Nous allons créer la règle suivante:

2016-12-07_10-09-46

 

On sélectionne All Content.

2016-12-07_10-10-58

 

On choisit de suivre des codes d’erreur. On entre 404 ou une plage qui contient 404 puisque c’est le symptôme observé.

 

2016-12-07_10-12-54

 

  • On ne sélectionne que le provider WWW Server
  • On ne sélectionne que l’area Rewrite

Voilà, c’est prêt.

 

Note: il peut arriver que Rewrite n’apparaît pas. Cela arrive si Fail Request Tracing a été installé après le module Url Rewriting.

La solution consiste à le réinstaller.

 

On relance le test et on passe à la session de débogage.

Débogage

Une façon de retrouver les fichiers de logs est le demander à l’outil de trace:

2016-12-07_10-16-27

On ouvre le fichier xml trouvé.

Le fichier est assez verbeux, mais comme on sait ce que l’on veut trouver ce sera plus simple!

Au début on trouve les conditions du test:

2016-12-07_10-19-46

Je vais m’intéresser aux Events:

2016-12-07_10-21-45

On apprend que la règle de substitution a généré l’url suivante:

https://www.fdlm.com/demo/1234

Le 404 s’explique donc, on attaque un domaine (fdlm.com) qui n’a pas été inscrit. La page ne peut donc être trouvée.

 

Bibliographie

https://www.iis.net/learn/extensions/url-rewrite-module/using-failed-request-tracing-to-trace-rewrite-rules

 

 

 

 

 

 

 

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s