Quand Firebug ne suffit plus

Ça m'est arrivé à quelques reprises d'avoir à travailler avec un composant Flash qui soit paramétré pour faire appel à un script PHP quelque part dans son mécanisme interne (je pense entre autre à Uploadify 2.1.4). Le problème dans ce cas-ci, c'est que lorsqu'une erreur se produit côté serveur, le message explicite renvoyé par PHP est filtré par le composant Flash pour fournir une réponse amicale pour le commun des mortels (du type HTTP error) et ainsi ne rien dévoiler de compromettant. Rien d'utile pour nous aider pendant la phase de développement et de débogage.



Comme d'habitude, je me suis tourné vers Firebug mais comme l'appel à la page PHP est délégué à Flash, il n'apparaît nulle part (ni dans les XHR de Firebug même si au fond, Flash utilise une technique identique). C'est une des rares limitations que j'ai rencontré avec le traçage de Firebug jusqu'à maintenant.

J'ai tenté d'accéder directement au script PHP pour détecter toute erreur de syntaxe, sans rien y trouver. Et comme il est exécuté en dehors du contexte du composant Flash qui l'appelle et qu'on ne voit pas quels paramètres lui sont envoyés, la manoeuvre est biaisée. Il me faut tout voir pour bien comprendre.

Parfois, le meilleur moyen de suivre à la loupe tout ce qui se passe est de capturer et d'analyser les requêtes du protocole HTTP à l'aide d'un Web Debugging Proxy. J'avais déjà essayé Charles il y a quelques années, un outil commercial multi-plateformes, mais pour le moment, un équivalent gratuit nommé Fiddler sera suffisant même s'il est limité à l'environnement Windows.

Assurez-vous d'abord dans la configuration PHP que le flag display_errors soit activé. Autrement, vous ne verrez rien (sauf par le log d'erreur de PHP qui se trouve sur le serveur). Et dans le cas d'Uploadify, ne vous fiez pas toujours à la confirmation de transfert car l'interface affiche parfois un succès même s'il rencontre un warning (difficile à détecter puisque seule une entête HTTP 500 indiquera dans l'interface une erreur côté serveur).

Une fois ceci réglé, on pourra improviser une solution en utilisant la bonne vieille méthode d'impression avec des instructions "echo" ou "print_r" en guise de trace. Dans la portion de gauche, cliquez sur la requête HTTP à décortiquer. Son détail apparaîtra sous différentes vues dans la portion de droite (onglet Inspectors). Si vous avez configuré proprement le report des erreurs PHP et que vous ne les prenez pas en charge par un handler particulier, vous devriez aussi les voir apparaître à droite. Les détails de la requête sont en haut, ceux de la réponse du serveur en bas.

Exemple de trace forcée par le code PHP :

header('HTTP/1.1 500 Internal Server Error');



echo "Étape 1\n";

echo "Valeur A: 123\n";

echo "Valeur B: 456\n";

echo "Valeurs POST: \n";

print_r($_POST);



echo "Étape 2\n";

echo "--> trace ici...";

exit;

Résultat dans Fiddler (cliquez pour agrandir) :



J'attire votre attention sur les deux boutons TextView qui seront utiles pour visualiser plus facilement les détails. Pour l'instant, c'est suffisant pour que vous puissiez pousser plus loin votre investigation en cas de problème.

N.B. le logiciel est gratuit mais souvenez-vous qu'un programmeur se cache derrière tout ce travail. Tout comme au restaurant lorsque vous recevez un bon service, vous pouvez laisser un pourboire à l'auteur en utilisant PayPal mais plus original encore, vous pouvez lui donner une commission de 7% (sans frais pour vous) sur votre prochain achat chez Amazon en magasinant à partir du lien du menu $Donate qu'il a glissé dans son application. C'est ce que je ferai la prochaine fois.