Comment puis-je dépanner mon script Perl CGI?

J'ai un script Perl qui ne fonctionne pas et je ne sais pas comment commencer à réduire le problème. Que puis-je faire?

Remarque: j'ajoute la question parce que je veux vraiment ajouter ma très longue réponse à Stackoverflow. Je continue à faire des liens externes avec cela dans d'autres réponses et cela mérite d'être ici. N'hésitez pas à modifier ma réponse si vous avez quelque chose à ajouter.

Cette réponse est conçue comme un cadre général pour résoudre les problèmes avec les scripts Perl CGI et est apparue à l'origine sur Perlmonks en tant que Dépannage des scripts Perl CGI . Ce n'est pas un guide complet de tous les problèmes que vous pourriez rencontrer, ni un tutoriel sur la correction des bogues. C'est juste le point culminant de mon expérience de débogage de scripts CGI pendant vingt (plus!) Ans. Cette page semble avoir eu de nombreuses maisons différentes, et je semble oublier qu'elle existe, donc je l'ajoute à StackOverflow. Vous pouvez m'envoyer vos commentaires ou suggestions à bdfoy@cpan.org. C'est aussi un wiki communautaire, mais ne devenez pas trop fou. :)

Utilisez-vous les fonctionnalités intégrées de Perl pour vous aider à trouver des problèmes?

Activez les avertissements pour laisser Perl vous avertir des parties douteuses de votre code. Vous pouvez le faire à partir de la ligne de commande avec le -wcommutateur afin de ne pas avoir à changer de code ou à ajouter un pragma à chaque fichier:

 % perl -w program.pl

Cependant, vous devez vous forcer à toujours effacer le code douteux en ajoutant le warningspragma à tous vos fichiers:

 use warnings;

Si vous avez besoin de plus d'informations que le court message d'avertissement, utilisez le diagnosticspragma pour obtenir plus d'informations, ou consultez la documentation de perldiag :

 use diagnostics;

Avez-vous d'abord sorti un en-tête CGI valide?

Le serveur s'attend à ce que la première sortie d'un script CGI soit l'en-tête CGI. En règle générale qui pourrait être aussi simple que print "Content-type: text/plain\n\n";ou avec CGI.pm et ses dérivés, print header(). Certains serveurs sont sensibles à la sortie d'erreur (surSTDERR ) apparaissant avant la sortie standard (activée STDOUT).

Essayez d'envoyer des erreurs au navigateur

Ajouter cette ligne

 use CGI::Carp 'fatalsToBrowser';

à votre script. Cela envoie également des erreurs de compilation à la fenêtre du navigateur. Veillez à le supprimer avant de passer à un environnement de production, car les informations supplémentaires peuvent constituer un risque pour la sécurité.

Que dit le journal des erreurs?

Les serveurs conservent des journaux d'erreurs (ou ils devraient, au moins). La sortie d'erreur du serveur et de votre script devrait apparaître là-haut. Trouvez le journal des erreurs et voyez ce qu'il dit. Il n'y a pas d'espace standard pour les fichiers journaux. Recherchez leur emplacement dans la configuration du serveur ou demandez à l'administrateur du serveur. Vous pouvez également utiliser des outils tels que CGI :: Carp pour conserver vos propres fichiers journaux.

Quelles sont les autorisations du script?

Si vous voyez des erreurs telles que «Autorisation refusée» ou «Méthode non implémentée», cela signifie probablement que votre script n'est pas lisible et exécutable par l'utilisateur du serveur Web. Sur les versions d'Unix, en changeant le mode 755 est recommandé: chmod 755 filename. Ne définissez jamais un mode sur 777!

Utilisez-vous use strict?

N'oubliez pas que Perl crée automatiquement des variables lorsque vous les utilisez pour la première fois. Ceci est une fonctionnalité, mais peut parfois causer des bogues si vous saisissez mal un nom de variable. Le pragma use strict vous aidera à trouver ce genre d'erreurs. C'est ennuyeux jusqu'à ce que vous vous y habituiez, mais votre programmation s'améliorera considérablement après un certain temps et vous serez libre de faire différentes erreurs.

Le script se compile-t-il?

Vous pouvez vérifier les erreurs de compilation en utilisant le -c commutateur. Concentrez-vous sur les premières erreurs signalées. Rincez, répétez. Si vous rencontrez des erreurs vraiment étranges, vérifiez que votre script a les bonnes fins de ligne. Si vous effectuez un FTP en mode binaire, une extraction depuis CVS ou quelque chose d'autre qui ne gère pas la traduction de fin de ligne, le serveur Web peut voir votre script comme une seule grande ligne. Transférez les scripts Perl en mode ASCII.

Le script se plaint-il de dépendances non sécurisées?

Si votre script se plaint de dépendances non sécurisées, vous utilisez probablement le -Tcommutateur pour activer le mode taint, ce qui est une bonne chose car il vous permet de continuer à transmettre des données non vérifiées au shell. S'il se plaint, il fait son travail pour nous aider à écrire des scripts plus sécurisés. Toute donnée provenant de l'extérieur du programme (c'est-à-dire de l'environnement) est considérée comme corrompue. Les variables d'environnement telles que PATHet LD_LIBRARY_PATH sont particulièrement gênantes. Vous devez les définir sur une valeur sûre ou les désactiver complètement, comme je le recommande. Vous devriez de toute façon utiliser des chemins absolus. Si la vérification de l'altération se plaint d'autre chose, assurez-vous que vous n'avez pas altéré les données. Voir la page de manuel de perlsec pour plus de détails.

Que se passe-t-il lorsque vous l'exécutez à partir de la ligne de commande?

Le script produit-il ce que vous attendez lorsqu'il est exécuté à partir de la ligne de commande? L'en-tête est-il sorti en premier, suivi d'une ligne vide? N'oubliez pas que cela STDERRpeut être fusionné avec STDOUT si vous êtes sur un terminal (par exemple, une session interactive), et qu'en raison de la mise en mémoire tampon, cela peut apparaître dans un ordre confus. Activez la fonction autoflush de Perl en définissant $|une valeur vraie. En règle générale, vous pouvez voir $|++;dans les programmes CGI. Une fois définies, chaque impression et écriture ira immédiatement à la sortie plutôt que d'être mise en mémoire tampon. Vous devez définir ceci pour chaque descripteur de fichier. Utilisez selectpour changer le descripteur de fichier par défaut, comme ceci:

$|++;                            #sets $| for STDOUT
$old_handle = select( STDERR );  #change to STDERR
$|++;                            #sets $| for STDERR
select( $old_handle );           #change back to STDOUT

Dans tous les cas, la première sortie doit être l'en-tête CGI suivi d'une ligne vide.

Que se passe-t-il lorsque vous l'exécutez à partir de la ligne de commande avec un environnement de type CGI?

L'environnement du serveur Web est généralement beaucoup plus limité que votre environnement de ligne de commande et contient des informations supplémentaires sur la demande. Si votre script s'exécute correctement à partir de la ligne de commande, vous pouvez essayer de simuler un environnement de serveur Web. Si le problème apparaît, vous avez un problème d'environnement.

Annuler ou supprimer ces variables

• PATH
• LD_LIBRARY_PATH
• toutes les ORACLE_*variables

Définissez ces variables

• REQUEST_METHOD(fixé à GET, HEADou POSTselon le cas)
• SERVER_PORT (défini sur 80, généralement)
• REMOTE_USER (si vous faites des choses à accès protégé)

Les versions récentes de CGI.pm(> 2.75) nécessitent l' -debugindicateur pour obtenir l'ancien comportement (utile), vous devrez donc peut-être l'ajouter à vos CGI.pmimportations.

use CGI qw(-debug)

Utilisez-vous die()ou warn?

Ces fonctions s'impriment STDERRsauf si vous les avez redéfinies. Ils ne produisent pas non plus d'en-tête CGI. Vous pouvez obtenir la même fonctionnalité avec des packages tels que CGI :: Carp

Que se passe-t-il après avoir vidé le cache du navigateur?

Si vous pensez que votre script fait la bonne chose et que lorsque vous exécutez la requête manuellement, vous obtenez le bon résultat, le navigateur peut être le coupable. Videz le cache et définissez la taille du cache sur zéro pendant le test. N'oubliez pas que certains navigateurs sont vraiment stupides et ne rechargeront pas réellement le nouveau contenu même si vous leur dites de le faire. Ceci est particulièrement répandu dans les cas où le chemin de l'URL est le même, mais le contenu change (par exemple les images dynamiques).

Le script est-il là où vous pensez qu'il se trouve?

Le chemin du système de fichiers vers un script n'est pas nécessairement directement lié au chemin de l'URL du script. Assurez-vous d'avoir le bon répertoire, même si vous devez écrire un court script de test pour le tester. De plus, êtes-vous sûr de modifier le bon fichier? Si vous ne voyez aucun effet avec vos modifications, vous êtes peut-être en train de modifier un autre fichier ou de télécharger un fichier au mauvais endroit. (C'est d'ailleurs ma cause la plus fréquente de tels problèmes;)

Utilisez-vous CGI.pmou un dérivé de celui-ci?

Si votre problème est lié à l' analyse de l'entrée de CGI et vous n'êtes pas en utilisant un module largement testé comme CGI.pm, CGI::Request, CGI::Simpleou CGI::Lite, utilisez le module et se concentrer sur la vie. CGI.pma un cgi-lib.plmode de compatibilité qui peut vous aider à résoudre les problèmes d'entrée dus aux anciennes implémentations de l'analyseur CGI.

Avez-vous utilisé des chemins absolus?

Si vous exécutez des commandes externes avec system, des graduations inverses ou d'autres fonctions IPC, vous devez utiliser un chemin absolu vers le programme externe. Non seulement vous savez exactement ce que vous exécutez, mais vous évitez également certains problèmes de sécurité. Si vous ouvrez des fichiers en lecture ou en écriture, utilisez un chemin absolu. Le script CGI peut avoir une idée différente de la vôtre sur le répertoire actuel. Alternativement, vous pouvez faire un explicite chdir()pour vous mettre au bon endroit.

Avez-vous vérifié vos valeurs de retour?

La plupart des fonctions Perl vous diront si elles ont fonctionné ou non et seront activées $!en cas d'échec. Avez-vous vérifié la valeur de retour et examiné $!les messages d'erreur? Avez-vous vérifié $@si vous utilisiez eval?

Quelle version de Perl utilisez-vous?

La dernière version stable de Perl est la 5.28 (ou non, selon la date de la dernière modification). Utilisez-vous une ancienne version? Différentes versions de Perl peuvent avoir différentes idées d'avertissement.

Quel serveur Web utilisez-vous?

Différents serveurs peuvent agir différemment dans la même situation. Le même produit serveur peut agir différemment avec différentes configurations. Incluez autant de ces informations que possible dans toute demande d'aide.

Avez-vous vérifié la documentation du serveur?

Les programmeurs CGI sérieux doivent en savoir autant que possible sur le serveur - y compris non seulement les fonctionnalités et le comportement du serveur, mais également la configuration locale. La documentation de votre serveur peut ne pas être disponible si vous utilisez un produit commercial. Sinon, la documentation doit être sur votre serveur. Si ce n'est pas le cas, recherchez-le sur le Web.

Avez-vous recherché les archives de comp.infosystems.www.authoring.cgi?

Cette utilisation était utile, mais toutes les bonnes affiches sont soit mortes, soit errantes.

Il est probable que quelqu'un ait déjà eu votre problème et que quelqu'un (peut-être moi) y ait répondu dans ce groupe de discussion. Bien que ce groupe de discussion ait passé son apogée, la sagesse recueillie du passé peut parfois être utile.

Pouvez-vous reproduire le problème avec un court script de test?

Dans les grands systèmes, il peut être difficile de localiser un bogue car il se passe tellement de choses. Essayez de reproduire le problème avec le script le plus court possible. Connaître le problème est l'essentiel du correctif. Cela peut certainement prendre du temps, mais vous n'avez pas encore trouvé le problème et vous manquez d'options. :)

Avez-vous décidé d'aller voir un film?

Sérieusement. Parfois, nous pouvons être tellement absorbés par le problème que nous développons un «rétrécissement perceptif» (vision tunnel). Prendre une pause, prendre une tasse de café ou faire exploser des méchants dans [Duke Nukem, Quake, Doom, Halo, COD] pourrait vous donner la nouvelle perspective dont vous avez besoin pour ré-aborder le problème.

Avez-vous exprimé le problème?

Sérieusement encore. Parfois, expliquer le problème à haute voix nous conduit à nos propres réponses. Parlez au pingouin (peluche) parce que vos collègues n'écoutent pas. Si cela vous intéresse en tant qu'outil de débogage sérieux (et je le recommande si vous n'avez pas encore trouvé le problème), vous pouvez également lire The Psychology of Computer Programming .

Je pense que CGI :: Debug mérite également d'être mentionné.

dieles instructions et autres erreurs fatales lors de l'exécution et de la compilation sont imprimées STDERR, ce qui peut être difficile à trouver et peut être confondu avec des messages provenant d'autres pages Web de votre site. Pendant que vous déboguez votre script, il est judicieux d'afficher les messages d'erreur fatale dans votre navigateur.

Une façon de faire est d'appeler

   use CGI::Carp qw(fatalsToBrowser);

en haut de votre script. Cet appel installera un $SIG{__DIE__}gestionnaire (voir perlvar ) affichant des erreurs fatales dans votre navigateur, en le précédant d'un en-tête valide si nécessaire. Une autre astuce de débogage CGI que j'ai utilisée avant d'en entendre parler CGI::Carpétait d'utiliser evalavec les installations DATAet __END__sur le script pour détecter les erreurs de compilation:

   #!/usr/bin/perl
   eval join'', <DATA>;
   if ($@) { print "Content-type: text/plain:\n\nError in the script:\n$@\n; }
   __DATA__
   # ... actual CGI script starts here

Cette technique plus verbeuse a un léger avantage CGI::Carpen ce qu'elle détectera plus d'erreurs de compilation.

Mise à jour: je ne l'ai jamais utilisé, mais il semble CGI::Debug, comme l'a suggéré Mikael S, qu'il soit également un outil très utile et configurable à cet effet.

Je me demande pourquoi personne n'a mentionné l' PERLDB_OPTSoption appelée RemotePort; bien que certes, il n'y ait pas beaucoup d'exemples de travail sur le Web ( RemotePortn'est même pas mentionné dans perldebug ) - et c'était un peu problématique pour moi de trouver celui-ci, mais voilà (c'est un exemple Linux).

Pour faire un bon exemple, j'avais d'abord besoin de quelque chose qui puisse faire une simulation très simple d'un serveur Web CGI, de préférence via une seule ligne de commande. Après avoir trouvé le serveur Web de ligne de commande simple pour exécuter cgis. (perlmonks.org) , j'ai trouvé que IO :: All - A Tiny Web Server était applicable pour ce test.

Ici, je vais travailler dans le /tmprépertoire; le script CGI sera /tmp/test.pl(inclus ci-dessous). Notez que le IO::Allserveur ne servira que les fichiers exécutables dans le même répertoire que CGI, c'est donc chmod +x test.plobligatoire ici. Donc, pour faire le test CGI habituel, je change de répertoire /tmpdans le terminal et j'y lance le serveur Web à une ligne:

$ cd /tmp
$ perl -MIO::All -e 'io(":8080")->fork->accept->(sub { $_[0] < io(-x $1 ? "./$1 |" : $1) if /^GET \/(.*) / })'

La commande du serveur Web se bloquera dans le terminal, et sinon démarrera le serveur Web localement (sur 127.0.0.1 ou localhost) - après, je peux accéder à un navigateur Web et demander cette adresse:

http://127.0.0.1:8080/test.pl

... et je devrais observer le prints fait en test.plétant chargé - et affiché - dans le navigateur Web.

Maintenant, pour déboguer ce script avec RemotePort, nous avons d'abord besoin d'un écouteur sur le réseau, à travers lequel nous allons interagir avec le débogueur Perl; nous pouvons utiliser l'outil de ligne de commande netcat( nc, vu ça ici: Perl 如何 remote debug? ). Alors, lancez d'abord l' netcatécouteur dans un terminal - où il bloquera et attendra les connexions sur le port 7234 (qui sera notre port de débogage):

$ nc -l 7234

Ensuite, nous voudrions perldémarrer en mode débogage avec RemotePort, lorsque le test.pla été appelé (même en mode CGI, via le serveur). Cela, sous Linux, peut être fait en utilisant le script suivant "shebang wrapper" - qui ici doit également être dans /tmp, et doit être rendu exécutable:

cd /tmp

cat > perldbgcall.sh <<'EOF'
#!/bin/bash
PERLDB_OPTS="RemotePort=localhost:7234" perl -d -e "do '$@'"
EOF

chmod +x perldbgcall.sh

C'est un peu une chose délicate - voir script shell - Comment puis-je utiliser des variables d'environnement dans mon shebang? - Échange de piles Unix et Linux . Mais, l'astuce ici semble être de ne pas bifurquer l' perlinterpréteur qui gère test.pl - donc une fois que nous l'avons frappé, nous ne le faisons pas exec, mais à la place nous appelons perl"clairement", et fondamentalement "source" notre test.plscript en utilisant do(voir Comment exécuter un Script Perl depuis un script Perl? ).

Maintenant que nous avons perldbgcall.shdans /tmp- nous pouvons changer le test.plfichier, afin qu'il fasse référence à ce fichier exécutable sur sa ligne shebang (au lieu de l'interpréteur Perl habituel) - ici est /tmp/test.plmodifié ainsi:

#!./perldbgcall.sh

# this is test.pl

use 5.10.1;
use warnings;
use strict;

my $b = '1';
my $a = sub { "hello $b there" };
$b = '2';
print "YEAH " . $a->() . " CMON\n";
$b = '3';
print "CMON " . &$a . " YEAH\n";

$DB::single=1;  # BREAKPOINT

$b = '4';
print "STEP " . &$a . " NOW\n";
$b = '5';
print "STEP " . &$a . " AGAIN\n";

Maintenant, les deux test.plet son nouveau gestionnaire de shebang,, perldbgcall.shsont en /tmp; et nous ncécoutons les connexions de débogage sur le port 7234 - afin que nous puissions enfin ouvrir une autre fenêtre de terminal, changer de répertoire /tmpet exécuter le serveur Web à une ligne (qui écoutera les connexions Web sur le port 8080) là:

cd /tmp
perl -MIO::All -e 'io(":8080")->fork->accept->(sub { $_[0] < io(-x $1 ? "./$1 |" : $1) if /^GET \/(.*) / })'

Une fois que cela est fait, nous pouvons accéder à notre navigateur Web et demander la même adresse, http://127.0.0.1:8080/test.pl . Cependant, maintenant, lorsque le serveur Web essaiera d'exécuter le script, il le fera via perldbgcall.shshebang - qui démarrera perlen mode débogueur distant. Ainsi, l'exécution du script s'arrêtera - et ainsi le navigateur Web se verrouillera, en attendant les données. Nous pouvons maintenant passer au netcatterminal, et nous devrions voir le texte familier du débogueur Perl - cependant, sortir via nc:

$ nc -l 7234

Loading DB routines from perl5db.pl version 1.32
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(-e:1):   do './test.pl'
  DB<1> r
main::(./test.pl:29):   $b = '4';
  DB<1>

Comme le montre l'extrait de code, nous utilisons maintenant essentiellement nccomme un "terminal" - afin que nous puissions taper r(et Enter) pour "run" - et le script exécutera l'instruction breakpoint (voir aussi En perl, quelle est la différence entre $ DB :: single = 1 et 2? ), Avant de s'arrêter à nouveau (notez qu'à ce stade, le navigateur se verrouille toujours).

Donc, maintenant nous pouvons, disons, parcourir le reste de test.pl , via le ncterminal:

....
main::(./test.pl:29):   $b = '4';
  DB<1> n
main::(./test.pl:30):   print "STEP " . &$a . " NOW\n";
  DB<1> n
main::(./test.pl:31):   $b = '5';
  DB<1> n
main::(./test.pl:32):   print "STEP " . &$a . " AGAIN\n";
  DB<1> n
Debugged program terminated.  Use q to quit or R to restart,
  use o inhibit_exit to avoid stopping after program termination,
  h q, h R or h o to get additional info.
  DB<1>

... cependant, également à ce stade, le navigateur se verrouille et attend les données. Seulement après avoir quitté le débogueur avec q:

  DB<1> q
$

... le navigateur arrête-t-il le verrouillage - et affiche finalement la sortie (complète) de test.pl :

YEAH hello 2 there CMON
CMON hello 3 there YEAH
STEP hello 4 there NOW
STEP hello 5 there AGAIN

Bien sûr, ce type de débogage peut être effectué même sans exécuter le serveur Web - cependant, la chose intéressante ici, c'est que nous ne touchons pas du tout au serveur Web; nous déclenchons l'exécution "nativement" (pour CGI) à partir d'un navigateur Web - et le seul changement nécessaire dans le script CGI lui-même est le changement de shebang (et bien sûr, la présence du script wrapper shebang, en tant que fichier exécutable dans le même annuaire).

Eh bien, j'espère que cela aide quelqu'un - j'aurais certainement aimé tomber dessus, au lieu de l'écrire moi-même :)
.

Pour moi, j'utilise log4perl . C'est assez utile et facile.

use Log::Log4perl qw(:easy);

Log::Log4perl->easy_init( { level   => $DEBUG, file    => ">>d:\\tokyo.log" } );

my $logger = Log::Log4perl::get_logger();

$logger->debug("your log message");

Honnêtement, vous pouvez faire toutes les choses amusantes ci-dessus. BIEN QUE, la solution la plus simple et la plus proactive que j'ai trouvée était de simplement «l'imprimer».

Par exemple: (code normal)

`$somecommand`;

Pour voir s'il fait ce que je veux vraiment qu'il fasse: (Dépannage)

print "$somecommand";

Il vaudra probablement également la peine de mentionner que Perl vous indiquera toujours sur quelle ligne l'erreur se produit lorsque vous exécutez le script Perl à partir de la ligne de commande. (Une session SSH par exemple)

Je le ferai généralement si tout le reste échoue. Je vais SSH sur le serveur et exécuter manuellement le script Perl. Par exemple:

% perl myscript.cgi 

S'il y a un problème, Perl vous en informera. Cette méthode de débogage supprime tout problème lié à l'autorisation de fichier ou problème de navigateur Web ou de serveur Web.

Vous pouvez exécuter le script perl cgi dans le terminal en utilisant la commande ci-dessous

 $ perl filename.cgi

Il interprète le code et fournit le résultat avec du code HTML. Il signale l'erreur le cas échéant.