Le blog de Jimmy Articles qui n’ont plus toujours quelque chose à voir avec le web…

L’utilisation d’un HTTP debugger (aussi appelé “HTTP sniffer”, “HTTP watcher”, …etc) m’a déjà sauvé la mise plus d’une fois, et aujourd’hui, l’envie me prend de parler de cette pratique sur mon blog. C’est parti.

Qu’est-ce que c’est et comment ça marche

Bien connu des développeurs Ajax et Flash, un HTTP debugger est un programme (parfois gratuit, parfois payant, en plug-in ou standalone) qu’il faut installer sur sa machine. Une fois lancé, ce soft vous permet de voir la liste des requêtes HTTP partant de votre machine vers l’extérieur.

Grâce à cet outil, on pourra, par exemple, voir la page web appelée, ainsi que toutes les autres resources requises pour le bon fonctionnement de la page : CSS, javascript, images, …

Exemple d’utilisation

Pour cet exemple, j’utilise un HTTP debugger appelé Fiddler.

Une fois lancé en parallèle à votre browser favori, voici le résultat produit par une visite sur la homepage de Google.

Dans ce screenshot on peut découvrir les colonnes suivantes :

• #: donne le numéro d’ordre dans lequel les resources sont arrivées dans le browser
• Result : (c’est fréquemment la donnée la plus intéressante pour moi) c’est le HTTP Status produit par la requête HTTP. (200=OK, 404=page not found, 304=not modified, …etc… voir la liste complète ici mais elle est plus jolie ici)
• Host: spécifie le hostname (utile pour vous y retrouver si vous surfez sur plusieurs sites en même temps)
• URL : adresse de la resource

D’autres colonnes sont disponibles, dont par exemple le ”Content-type”. En fonction de l’outil que vous choisirez (*), d’autres fonctionnalités +/- poussées seront disponibles, mais je vous laisse les découvrir par vous-même.

A quoi ça sert vraiment?

Dans l’exemple ci-dessus on voit que tout s’est bien passé : toutes les lignes (#4 - la page; #5 - une image *.png; #6 - une icône et #7 - une autre image *.png) affichent un status code égal à 200. Tout est donc parfait, mais ça n’est malheureusement pas toujours le cas.

Un HTTP debugger peut être utile à plein de gens, pour traiter plein de problèmes différents. Ci-dessous voici 4 exemples où ce genre d’outils m’a été utile.

1er exemple - détecter les erreurs 404 (”Document non trouvé”)

Dans cet exemple tiré d’une visite sur un site internet, on voit clairement qu’une image est manquante. Rien de bien gênant dans ce cas-ci (quoique), mais une erreur 404 se produisant sur une CSS ou pire, une librairie javascript, par exemple, peut être bloquante.

2ème exemple - Développer en Ajax ou collaborer avec des Flasheurs

Lorsque se produit une erreur 404 (ou une erreur 500) dans votre browser, pas moyen de la rater. Mais lorsqu’on travaille avec Ajax, ou avec Flash, cela donne lieu à des “requêtes HTTP invisibles” (et donc difficilement vérifiables) qui, pendant le développement, sont parfois buguées. Dans ce genre de cas, sans HTTP debugger, votre perte de temps pourrait se compter en heures d’autant qu’il est parfois difficile de reproduire ces requêtes manuellement. Impossible de se passer d’un debugger!

Ci-dessus, un appel Ajax (qui s’est bien passé ici - Result=200) capturé par Fiddler lors de la rédaction de ce présent article, sous WordPress.

3ème exemple - Appliquer et vérifier des règles de Search Engine Optimization

• Dans le cas de redirections (…), il est parfois nécessaire de spécifier explicitement un HTTP status code 301 - “Moved permanently” ou un HTTP status code 302 - “Moved temporarily”. Afin de vérifier le boulot, un HTTP debugger est nécessaire; (ex. en ASP: Response.Status = “301 Moved Permanently” Response.AddHeader “Location”, “my_page.asp”)
• Si votre serveur recueille toutes les erreurs 404 vers une jolie page custom, il faut parfois explicitement ajouter un code pour que le code renvoyé soit réellement 404, et ensuite vérifier le boulot avec un HTTP debugger;
• …

4ème exemple - Tester si la cache est vidée ou pas

Parfois, entre une modification de code, un “refresh”, une autre modif, un CTRL+F5, un vidage de la cache, on s’emmêle les pinceaux et on se sait pas toujours si ce qu’on voit vient de la cache ou pas. Un HTTP debugger peut effacer tous vos doutes :

• Si le code est 200 : ça ne vient pas de la cache
• si le code est 304 : ça vient de la cache (304 - not modified)

(*) Des outils sympa

http://www.fiddlertool.com/fiddler/ (certainement le plus laid de tous les HTTP Debuggers, mais néanmoins mon préféré - fonctionne avec FireFox en modifiant le proxy)

http://www.getfirebug.com/ (l’incontournable outil de FireFox!)

http://www.httpwatch.com/ (payant mais une version gratuite limitée est disponible et je la trouve jolie)

http://web-sniffer.net/ (en cas de détresse, une version web offrant moins de champ d’action)

Conclusion

Gardez à l’esprit que les HTTP Debuggers existent. Testez-en quelques uns, choisissez-en un, et ayez-le installé sur votre machine.