<-
Apache > Serveur HTTP > Documentation > Version 2.5 > Modules

Module Apache mod_cgi

Langues Disponibles:  en  |  fr  |  ja  |  ko 

Description:Exécution des scripts CGI
Statut:Base
Identificateur de Module:cgi_module
Fichier Source:mod_cgi.c

Sommaire

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.

Le module mod_cgid doit être utilisé à la place du module 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 également activé pour tout fichier possédant le type MIME application/x-httpd-cgi. L'utilisation du type MIME magic est obsolète.

Sujets

Directives

Traitement des bugs

Voir aussi

top

Les variables d'environnement CGI

Le serveur va définir les variables d'environnement CGI comme décrit dans la Spécification CGI, de la manière suivante :

PATH_INFO
Cette variable ne sera pas disponible si la directive 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.
REMOTE_HOST
Cette variable ne sera définie que si la directive 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.
REMOTE_IDENT
Cette variable ne sera définie que si la directive 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.
REMOTE_USER
Cette variable ne sera définie que si le script CGI fait l'objet d'une authentification.

Ce module utilise aussi les fonctions de base ap_add_common_vars et ap_add_cgi_vars pour ajouter des variables d'environnement comme :

DOCUMENT_ROOT
Prend la valeur définie par la directive DocumentRoot.
SERVER_NAME
Le nom de domaine pleinement qualifié pour la requête considérée
SERVER_ADDR
L'adresse IP du serveur virtuel qui traite la requête
SERVER_ADMIN
Prend la valeur définie par la directive ServerAdmin.

Pour une liste exhaustive de ces variables, vous pouvez écrire un script CGI basique qui extrait toutes les variables d'environnement passées par Apache selon un format adapté.

top

Débogage des scripts CGI

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. Ces directives permettent une journalisation plus détaillée des erreurs.

Format du fichier journal CGI

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).

top

Directive CGIScriptTimeout

Description:Le temps d'attente maximum pour une sortie du programme CGI
Syntaxe:CGIScriptTimeout time[s|ms]
Défaut:La valeur par défaut de la directive Timeout lorsqu'elle n'est pas définie
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Statut:Base
Module:mod_cgi

Cette directive permet de limiter le temps d'attente jusqu'à une prochaine sortie du programme CGI. Si ce temps est dépassé, le traitement de la requête et l'exécution du programme CGI sont terminés.

Exemple

CGIScriptTimeout 20
top

Directive ScriptLog

Description:Chemin du fichier journal des erreurs du script CGI
Syntaxe:ScriptLog chemin fichier
Contexte:configuration globale, serveur virtuel
Statut:Base
Module:mod_cgi, mod_cgid

La directive ScriptLog définit 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.

Exemple

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 soit le répertoire dans lequel se trouve le journal doit être accessible en écriture pour cet utilisateur, soit le fichier doit être 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 PAS 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 ce qui concerne la vitesse et l'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.

top

Directive ScriptLogBuffer

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 globale, serveur virtuel
Statut:Base
Module:mod_cgi, mod_cgid

Cette directive limite 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 modifie cette taille maximale, dont la valeur par défaut est de 1024 octets.

top

Directive ScriptLogLength

Description:Taille maximale du fichier journal des scripts CGI
Syntaxe:ScriptLogLength octets
Défaut:ScriptLogLength 10385760
Contexte:configuration globale, serveur virtuel
Statut:Base
Module:mod_cgi, mod_cgid

La directive ScriptLogLength définit 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.

Langues Disponibles:  en  |  fr  |  ja  |  ko 

top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.