Je suis tombé avant-hier sur un bug d'une fourberie incroyable qui m'aura couté une demi journée de fouille et de confusion totale. J'ai fini par y venir à bout, mais quand vous appendrez par quelle façon, vous tomberez des nues autant que moi. Ou alors, c'est que vous n'êtes pas développeurs et vous êtes alors dispensé de la lecture de cet article :)

Contexte

Wikio-experts, nouveau site de Wikio Group, dont je développe la partie front-end. Le formulaire d'inscription fonctionne évidemment très bien… mais pas sur Chrome. Et uniquement Chrome. Après avoir rempli et validé le formulaire, on revient sur le formulaire, désespérément vierge.

Fouille

Wikio-experts, comme OverBlog, utilise l'excellent framework Jelix qui propose, entre autre chose, une façon sécurisée de traiter les formulaires : jForms. Sans entrer dans les détails, le formulaire et toute ses données : champs, vérification des champs, gestion des erreurs, etc, sont stockés dans un objet PHP en session afin de faciliter les multiples aller retours entre clients et serveurs jusqu'à sa validation finale.

J'ai donc loggué le contenu de ma session juste avant d'envoyer le formulaire au client, et juste avant de traiter sa soumission. Résultat : avant, la session contient bien le jForm "signup", après, le jForm "signup" a disparu mais un jForm "login" est apparu.

Je fais alors le lien avec jAuth, le plugin d'authentification de Jelix sans pour autant comprendre par quel mystère on aurait pu appeler du code lié à jAuth dans ces circonstances. Je commente des parties de code, je désactive des trucs, je log ce qu'il se passe en tout début de script, debug classique quoi…

Et j'en arrive à la conclusion suivante :

Révélations !

Le formulaire ne fonctionne pas car le fichier /favicon.ico n'existe pas.

Ça vous la coupe hein ?

Mais comment qu'c'est possible ???

Chrome a pour habitude, comme nombre de navigateur, de vérifier si un fichier /favicon.ico existe, même si ce n'est pas spécifié dans la page web, au cas où. Sur le serveur, un classique .htaccess pour gérer les réécritures d'url qui, si l'url demandée n'existe pas, renvoit sur index.php?$1. Pour les non dev qui auraient survécu jusqu'ici, si un navigateur demande /favicon.ico et que ce fichier n'existe pas sur le serveur, le serveur renverra la même chose que si le navigateur avait demandé à accéder à /index.php?/favicon.ico.

Or, ce contrôleur n'existe évidemment pas dans mon application qui redirige automatiquement vers un contrôleur affichant une erreur 404. Et c'est là que se situait l'erreur. Mon application n'étant constitué à 99% que de pages nécessitant une authentification, je n'avais jamais remarqué que j'avais oublié de spécifier que ce contrôleur ne nécessitait pas d'auth, qui alors, redirigeait vers le formulaire de login, lequel effectuait évidemment un clean de session et donc la perte de mon jForm d'inscription.

J'ai donc ajouté un joli favicon.ico et les utilisateurs Chrome ont pu enfin s'inscrire -_-"

La question qui reste encore en suspend est : "pourquoi seul Chrome a-t-il été impacté par ce bug ?"
Je suppose que les autres browsers, qui ne s'embêtent pas à tenter eux aussi de chopper le favicon.ico, s'arrêtent immédiatement si la première réponse du serveur n'est pas un 200… Si quelqu'un peut apporter une réponse ?