Serveur Apache HTTP Version 2.4
Description: | Exécution des scripts CGI |
---|---|
Statut: | Base |
Identificateur de Module: | cgi_module |
Fichier Source: | mod_cgi.c |
Tout fichier pris en compte par le gestionnaire
cgi-script
sera traité en tant que script CGI et
exécuté par le serveur, sa sortie étant renvoyée au client. Les
fichiers sont associés à ce gestionnaire soit parce qu'ils possèdent
un nom contenant une extension définie par la directive AddHandler
, soit parce qu'ils se
situent dans un répertoire défini par une directive ScriptAlias
.
Comme introduction à l'utilisation des scripts CGI avec Apache, voir notre tutoriel Les contenus dynamiques avec CGI.
Il est recommandé d'utiliser le module mod_cgid
à la place de mod_cgi
lorsqu'on utilise un module MPM
multi-threadé sous Unix. Vus de l'utilisateur, les deux modules
sont pratiquement identiques.
À des fins de compatibilité ascendante, le gestionnaire
cgi-script sera aussi activé pour tout fichier possédant le type
MIME application/x-httpd-cgi
. L'utilisation du type
MIME magic est obsolète.
Le serveur va définir les variables d'environnement CGI comme décrit dans la Spécification CGI, de la manière suivante :
AcceptPathInfo
est
explicitement définie à off
. Par défaut, si la
directive AcceptPathInfo
n'est pas définie,
mod_cgi
acceptera des informations de chemin (en
ajoutant /infos/chemin après le nom du script dans l'URI), alors
que le serveur de base retournera une erreur 404 NOT FOUND pour
les requêtes contenant des informations de chemin supplémentaires.
Ne pas définir la directive AcceptPathInfo
a le même effet sur les requêtes avec mod_cgi
que
de la définir à On
.HostnameLookups
est définie à
on
(elle est à off
par défaut), et si
une recherche DNS inverse sur l'adresse IP de l'hôte client
aboutit effectivement à un nom d'hôte.IdentityCheck
est définie à on
, et si l'hôte client supporte le
protocole ident. Notez que l'on ne peut accorder une confiance
aveugle au contenu de cette variable car il peut être aisément
falsifié, et si un mandataire s'intercale entre le client et le
serveur, il est totalement inutilisable.Le débogage des scripts CGI était difficile par le passé, principalement parce qu'il n'était pas possible d'étudier la sortie (sortie standard et erreurs) des scripts dont l'exécution échouait. Les directives qui suivent permettent une journalisation plus détaillée des erreurs.
Lorsqu'il est configuré, le journal des erreurs CGI enregistre la sortie de tout programme CGI dont l'exécution ne s'effectue pas correctement. Un script CGI dont l'exécution échoue provoque la journalisation d'une grande quantité d'informations. Les deux premières lignes possèdent toujours le format suivant :
%% [date] requête
%% état HTTP nom du script CGI
Si le script CGI n'a pas pu démarrer, le fichier journal contiendra les deux lignes supplémentaires suivantes :
%%erreur
message d'erreur
Par contre, si l'erreur provient du renvoi par le script d'informations incorrectes dans les en-têtes (dû souvent à une bogue du script), les informations suivantes sont journalisées :
%requête
Tous les en-têtes de requête HTTP reçus
Les entités POST ou PUT (s'il en existe)
%réponse
Tous les en-têtes générés par le script CGI
%stdout
la sortie standard CGI
%stderr
la sortie d'erreurs standard CGI
(Les parties %stdout et %stderr seront absentes si le script n'a rien envoyé sur la sortie standard ou la sortie d'erreurs).
Description: | Chemin du fichier journal des erreurs du script CGI |
---|---|
Syntaxe: | ScriptLog chemin fichier |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Base |
Module: | mod_cgi , mod_cgid |
La directive ScriptLog
permet de définir
le chemin du fichier journal des erreurs du script CGI. Si cette
directive n'est pas définie, aucune journalisation des erreurs n'est
effectuée. Si elle est définie, toute erreur CGI sera enregistrée
dans le fichier dont le nom est fourni en argument. S'il s'agit d'un
chemin de fichier relatif, il est considéré par rapport au
répertoire défini par la directive ServerRoot
.
ScriptLog logs/cgi_log
Ce journal sera ouvert par l'utilisateur sous lequel les
processus enfants s'exécutent, c'est à dire l'utilisateur spécifié
par la directive du serveur User
. Ceci implique que le
répertoire dans lequel se trouve le journal doit être accessible en
écriture pour cet utilisateur, ou bien que le fichier est créé
manuellement et accessible en écriture pour cet utilisateur. Si vous
placez le journal du script dans votre répertoire principal des
journaux, ne modifiez JAMAIS les permissions de ce
dernier afin de le le rendre accessible en écriture par
l'utilisateur sous lequel les processus enfants s'exécutent.
Notez que l'on ne doit activer la journalisation des scripts qu'à des fins de débogage lors de l'écriture de scripts CGI, et non de manière permanente sur un serveur en production. Elle n'est pas optimisée en terme de performances et d'efficacité, et peut présenter des problèmes de sécurité si on l'utilise dans un cadre autre que celui pour lequel elle a été conçue.
Description: | Taille maximale des requêtes PUT ou POST qui seront enregistrées dans le journal du script |
---|---|
Syntaxe: | ScriptLogBuffer octets |
Défaut: | ScriptLogBuffer 1024 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Base |
Module: | mod_cgi , mod_cgid |
Cette directive permet de limiter la taille du corps de toute entité PUT ou POST qui sera enregistrée dans le journal, afin de prévenir une croissance trop importante et trop rapide du fichier journal due à la réception de corps de requête de grandes tailles. Cette directive permet de modifier cette taille maximale, dont la valeur par défaut est de 1024 octets.
Description: | Taille maximale du fichier journal des scripts CGI |
---|---|
Syntaxe: | ScriptLogLength octets |
Défaut: | ScriptLogLength 10385760 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Base |
Module: | mod_cgi , mod_cgid |
La directive ScriptLogLength
permet de
définir la taille maximale du fichier journal des scripts CGI. Comme
le fichier journal accumule une grande quantité d'informations par
erreur CGI (tous les en-têtes de la requête, toutes les sorties du
script), il peut vite atteindre une grande taille. En limitant la
taille du fichier, cette directive permet d'éviter les problèmes que
causerait sa croissance sans limites. Lorsque le fichier a atteint
cette taille maximale, plus aucune information n'y est
enregistrée.