L'installation des CGI n'est généralement pas une tâche difficile, mais les causes d'un mauvais fonctionnement sont nombreuses. Et il n'est pas toujours facile de déterminer laquelle (ou lesquelles!) entre(nt) en jeu lorsqu'un problème survient. Nous prenons dans toute la suite l'exemple d'un CGI en Perl.

Erreur 500
L'erreur la plus fréquente qui s'affichera lorsque, depuis le navigateur, vous essayez de lancer un script CGI est l'Internal Server Error (erreur 500). Si tel est le cas, la première chose à faire est de s'assurer que le chemin de l'interpréteur Perl est correctement spécifié sur la première ligne du script. Habituellement, sous serveur tournant sous Unix, ce chemin est :

/usr/bin/perl

ou parfois :

/usr/local/bin/perl

Si le problème persiste, c'est peut-être aussi que les fichiers Perl ont été transférés (via FTP du poste local du développeur au serveur) en mode non ASCII. Par ailleurs, le serveur http peut être tout simplement en cause (il faut alors le vérifier auprès de l'administrateur).
Aucune de ces deux solutions n'est la bonne ? Alors une erreur de syntaxe se cache dans le script, qui se termine abruptement, causant l'Internal Server Error. Consultez les fichiers log du serveur http (error.log sous Apache) afin de connaître la ligne exacte où est survenue l'erreur, et débuggez.

Autres problèmes
L'erreur 500 n'est malheureusement pas la seule. Il peut s'agir d'une erreur 400 (impossible de trouver la page), due généralement (en dehors d'une syntaxe incorrecte de l'URL du script) au fait que, sous Unix, les droits d'exécution du script CGI soient erronés. Ces derniers doivent généralement permettre à tous d'exécuter le script (mais pas de le modifier ou de le lire). Egalement, si le navigateur essaye de télécharger le script, alors le répertoire (usuellement cgi-bin, sous la racine) n'est pas configuré pour l'exécution des CGI (voir les fichiers de configuration du serveur).

Encore plus problématique, le script s'exécute sans qu'une erreur ne s'affiche, mais il ne se passe rien, ou le script semble s'arrêter sans avoir complété sa tâche. Dans ces cas là, il faut vérifier scrupuleusement les spécifications de chemin d'accès qui figurent dans les variables de configuration (le cas échéant) du CGI (et non plus du serveur). Certains serveurs requièrent, par leur paramétrage, que le chemin absolu soit précisé, et non le chemin relatif. Attention à ne pas confondre chemins sur le serveur (quelque chose comme /home/www/cgi-bin/test.pl sous Unix) et URLs.
Si cela ne fonctionne toujours pas, c'est peut-être parce que le CGI a essayé d'écrire dans un répertoire où les droits en écriture ne sont pas établis, puis a essayé de lire ce qui devait être écrit et ne l'a pas été. Réglez les droits en écriture des répertoires destinés à recevoir des données venant du CGI et testez de nouveau, avec toujours un regard sur les fichiers logs.

Si malgré tout, ça ne marche pas
Revoyez le code, il y a peut-être une erreur de cohérence. S'il s'agit d'un script téléchargé, dont la fiabilité est prouvée, soyez bien sûr qu'il ne requiert pas un module Perl que vous ne possédez pas, où que votre version de l'interpréteur Perl n'est pas trop ancienne. Les scripts proposés en téléchargement s'accompagnent souvent, s'ils sont payants, d'un support ou du moins (et parfois aussi pour les scripts gratuits) d'un forum de discussion plus ou moins complet qui recense les différents problèmes qu'ont connus les utilisateurs, et les réponses à ces problèmes.