Assez fréquemment, Bob B. observa que le site d'e-commerce de sa société se plantait méchamment. Personne n'avait d'indices sur la cause du problème mais tout le monde savait comment le régler. Redémarrer aussi bien SQL Server que IIS et voilà, dans la minute, le site était en fonctionnement.

Comme une veille voiture avec ses quelques bizarreries, la société s'inquiétait des conséquences d'un bricolage sur le site, pensant que cela ne ferait qu'empirer les choses. Pourtant, après quelques mois et des dizaines de réclamations clients, Bob fut autorisé à rechercher la cause du problème, en ayant néanmoins pour consigne de ne pas être trop intrusif.

En attendant le bug.

Le premier problème que Bob rencontra fût avec le module de log fait maison. Qu'importe la façon dont l'application plantait, le module de log planterait aussi, laissant Bob avec un fichier remplit de "erreur lors de l'écriture dans les logs". Quelques semaines et un plantage ou deux après, Bob avait corrigé le module de log et déploya l'application en production.

Cela ne prit pas trop de temps pour voir se produire un nouveau gros plantage. Bob plongea directement dans le fichier de log et vit la redouté erreur "server out of memory" de SQL Server. Une recherche sur google révéla que l'installation d'un service pack résoudrait très certainement les choses. Donc, après avoir cajolé le patron pour le laisser installer la mise à jour, Bob eut son service pack installé. A ce stade il ne restait plus qu’à attente pour voir ce qui allait se produire.

Plusieurs semaines de tensions passèrent sans qu'aucun plantage se soit rapporté, Bob en conclu que le service pack avait résolu le problème. Puis, le site se planta de nouveau, avec toujours le même message d'erreur "Serveur out of memory". Bob chercha donc plus loin et découvrit que le serveur était, en effet, en rupture mémoire. La raison semblait évidente : il y avait près de 2 000 000 session visiteurs ouvertes.Pour un site e-commerce avec une moyenne d'un millier de commandes par jour, deux millions de visiteurs étaient éloigné de l'ordinaire.

Bob se posa la question d'une attaque DoS (Dénis de service) mais la mis rapidement de coté. Personne ne pouvait raisonnablement vouloir s'embêter avec une attaque DoS sur leur site.

En encerclant le bug

Bob regarda alors les fichiers de log d’IIS aux alentours de l'heure du crash mais ne vit pas de pistes intéressantes. Le fichier comportait des lignes de log banales.  Après une demi-heure de lecture ligne par ligne, Bob relâcha la touche défilement rapide alors qu’il réfléchissait à une meilleure approche. C'est alors qu'il remarqua un paquet de requêtes de la même adresse IP. En vérifiant d'autres ressources pour voir les entêtes des requêtes, il vit que l'adresse IP appartenait à un utilisateur d'AOL qui semblait surfer de quelque par en Ohio.

66.77.93.50 - [08:34:29] "GET /access?action= _
   _ forward&uri=%2Ferror.aspx HTTP/1.1" 302 - "-" "-" "-" 

66.77.93.50 - [08:34:29] "GET /error.aspx _
   _ HTTP/1.1" 302 - "-" "-" "-"

Les pièces du puzzle commençaient à se rassembler. Un internaute de l'Ohio était rentré dans une boucle infinie qui créait une nouvelle session à chaque itération. Apparemment l'utilisateur d'AOL était suffisamment patient pour laisser cette boucle tourner pendant presque 11 heures.


En désactivant les cookies de son navigateur et en tapant une adresse manuellement, Bob confirma qu'il pouvait déclencher une boucle de redirection sans fin. Mais le mystère restait entier sur le déclenchement de cette boucle par un visiteur. Bob replongea dans les logs jusqu'a ce qu'il trouve la première ligne de la requête du visiteur : C'était pour les icones de favoris, cette petite icone qui apparait a coté de la barre d'adresse du navigateur. Plus étrange encore, c'était la première et l'unique requête du surfeur de l'Ohio (mis à part les redirections bien sur).

66.77.93.50 - [08:34:29] _
   _ "GET /favicon.ico HTTP/1.1" 302 - "-" "-" "-"

Finalement, Bob comprit exactement comment le problème apparaissait : un visiteur aléatoire qui utilisait une vieille version d'AOL ajoutait le site à ses favoris. L'internaute n'essayait pas d'aller sur le site en attendant 11 heures que la page s'affiche. Il suffisait juste qu’il ouvre le navigateur d’AOL, celui ci tentait périodiquement de mettre à jour les icones des sites favoris, et ainsi suivait invariablement la voie de la douloureuse boucle infinie.Bob ajouta rapidement un fichier favicon.ico dans la racine du site et corrigea le problème de la boucle de redirection infinie. Le plantage ne se reproduisit pas.

L’histoire retiendra que, pendant un certain temps, le site web fût à la merci des habitudes de surf d'une famille vivant dans l'Ohio.