Vous venez de terminer la lecture de ce document, d'installer avec
succès votre serveur HTTP, d'écrire un script CGI en vous basant sur les
exemples fournis. Vous lancez votre navigateur pour faire un
test. D'ailleurs, à ce propos, utilisez bien Ouvrir URL pour
accéder au script, et non pas Ouvrir Fichier. Si votre machine
s'appelle yoda, et que vous avez placé le script date.cgi
dans le répertoire des scripts CGI, vous devez ouvrir l'URL
http://yoda/cgi-bin/date.cgi.
Et là, que voyez-vous apparaître à la place de la sortie attendue de
votre programme ? Le navigateur vous affiche une erreur du genre
Internal server error. Affreux.
Nous voilà donc lancé dans l'enfer du debug d'un script CGI. Disons tout de suite que le debug d'un script CGI n'est pas tout à fait le même problème que le debug d'un programme normal.
En effet, la plupart des programmes que vous avez écrits jusqu'à maintenant étaient lancés directement à partir de la ligne de commande. Ce n'est pas le cas des scripts CGI. Ils sont exécutés par une autre programme, le serveur HTTP, et souvent sur une machine différente de celle sur laquelle ils ont été écrits.
Si au lieu de la sortie attendue de votre programme, vous voyez s'afficher le code source du programme c'est que le serveur HTTP n'est pas configuré pour pouvoir exécuter des scripts CGI. Contacter l'administrateur du serveur, ou si c'est votre propre serveur relisez la partie Installation du serveur pour voir si vous l'avez correctement configuré.
Le secret du debug est donc de bien comprendre que c'est le serveur HTTP qui exécute le programme.
Gardons cela en tête, et commençons le debug de notre programme.
La première chose à vérifier est que le programme soit exécutable par
tous dans le cas d'un programme compilé, et lisible et exécutable par
tous dans le cas d'un script. Ceci parce que le serveur s'exécute sous
un nom d'utilisateur différent du votre. Donc une fois votre programme
installé dans le répertoire adéquat n'oubliez pas de faire un petit
chmod 555 date.cgi, par exemple.
Si cela ne marche toujours pas, il faut essayer d'exécuter le programme sur la ligne de commande pour voir ce qu'il affiche en sortie. En effet, quand votre programme est exécuté par le serveur HTTP, le résultat de sa sortie est envoyé au navigateur, et donc vous ne voyez en fait que ce qu'en fait le navigateur. Votre programme peut donc s'exécuter correctement sur le serveur, afficher quelque chose sur sa sortie standard, mais cette sortie est peut-être incohérente pour le navigateur, qui vous affiche alors un message d'erreur.
Exécutez donc votre programme sur la ligne de commande, qu'affiche
t'il en sortie ? Comme nous l'avons déjà vu précédemment, la première
ligne affichée doit être le champ Content-Type du header HTTP,
suivi par une ligne blanche. Si ce n'est pas le cas, corrigez-le. Une
erreur fréquente est, en langage C, l'instruction suivante :
printf("Content-Type: text/html\n");. Cette instruction est
syntaxiquement correcte, mais elle n'affiche pas de ligne blanche
après l'affichage de la chaîne. Le \n ne fait aller qu'à la
ligne. Il faut deux newline. L'instruction correcte est la
suivante : printf("Content-Type: text/html\n\n");. Ceci est
une des erreurs les plus fréquement commises au début de la
programmation de scripts CGI. Le reste de l'affichage, après le header
et la ligne blanche, doit être cohérent avec le header. Donc, dans ce
cas de figure, une sortie au format HTML. Par exemple:
Content-type: text/html <HTML><HEAD> <TITLE>Sortie Correcte</TITLE> </HEAD> <BODY> <H1>Ceci est une sortie correcte</H1> </BODY></HTML>
Ce test peut être suffisant si votre programme ne traite aucune donnée en entrée. Mais si votre programme traite des données, par exemple par l'intermédiaire d'un formulaire (voir le deuxième exemple), il faut tester le programme dans les conditions les plus proches du réel, et donc lui passer des arguments en entrée.
Si le formulaire utilise la méthode GET, votre programme récupère les
données par l'intermédiaire de la variable d'environnement
QUERY_STRING. On peut alors facilement affecter une valeur à
cette variable sous le shell. Par exemple, en bash :
export QUERY_STRING="prenom=Marcel&nom=Gnou&age=41+%E0+60+ans"
Il faut affecter une valeur la plus proche possible du réel (donc
éventuellement avec les %xx correspondant aux caractères
accentués et réservés). On peut alors exécuter le programme sur la
ligne de commande et étudier sa sortie.
Enfin, si votre script doit être installé sur une autre machine que
celle sous laquelle vous l'avez écrit, pensez à vérifier les chemins
(path) des programmes que vous utilisez. Dans l'exemple de
date.cgi, le programme peut planter (et donc votre navigateur
vous affiche un message d'erreur), si par exemple le programme
date ne se trouve pas dans le répertoire /bin. Votre
programme, donnant une sortie correcte sur votre machine, exécuté sur
l'autre machine, affichera en sortie :
./date.cgi: /bin/date: command not found Content-type: text/html <HTML><HEAD><TITLE>Script Cgi</TITLE><HEAD> <BODY> <CENTER> <H1>La date courante sur le serveur est</H1> </CENTER> </BODY> </HTML>
Ce qui, vous en conviendrez, n'est pas une sortie correcte. Le
problème peut se poser également avec les scripts écrits en Perl. En
effet, dans nos exemples, on supposait que Perl se trouvait dans le
répertoire /usr/bin/ (première ligne de nos scripts :
#!/usr/bin/perl). Si sur la machine sur laquelle doit
s'exécuter notre programme perl ne se trouve pas dans ce répertoire
nous aurions commme sortie :
./env.pl: No such file or directory
Ce qui n'est pas une sortie attendue par un navigateur.