Cours PDF Scripts CGI : Apprendre à Créer des Pages Dynamiques (Débutant)
Ce support de cours au format PDF permet de maîtriser l'interface CGI sans frais.
Le Common Gateway Interface (CGI) est une spécification et une interface standardisée pour l'échange de données entre un serveur web et un programme externe. Le PDF téléchargeable présente des méthodes pratiques pour créer des pages web dynamiques et interagir avec des bases de données. Auteur : Frédéric Couchet.
Prérequis techniques
Maîtrise de HTML pour structurer les réponses, notions de ligne de commande Unix pour gérer permissions et shebang, et connaissance basique d'un langage de script (Perl, Python, Bash) pour écrire et déboguer des exécutables. Une compréhension élémentaire du protocole HTTP facilite l'interprétation des variables d'environnement et du flux stdin.
👤 À qui s'adresse ce cours ?
Destiné aux débutants ayant des notions de base en HTML et une familiarité minimale avec un langage de programmation (Perl, Python, Bash ou équivalent). Une compréhension du protocole HTTP et de la ligne de commande aide à gérer les permissions et le déploiement sur un serveur web Apache.
Common Gateway Interface (CGI) — Ce que vous allez apprendre
- Définition et rôle du Common Gateway Interface : comprendre le modèle client‑serveur et le fonctionnement de l'interface.
- Pourquoi utiliser les scripts CGI : avantages et cas d'usage pour des traitements côté serveur.
- Prérequis et choix techniques : compétences et options techniques avant d'écrire des scripts.
- Installation du serveur Web : configuration d'un serveur HTTP pour exécuter des scripts dans le répertoire
cgi-bin. - Architecture et flux de données : trajet des données entre navigateur et serveur, variables d'environnement et flux
stdin. - Premier programme : écrire, exécuter et déboguer un script simple.
- Lien avec les SSI (Server Side Includes) pour des inclusions côté serveur sans lancer d'exécutable.
📑 Sommaire du document
- Introduction au CGI
- Configuration Apache
- Variables d'environnement
- Gestion des formulaires
- Sécurité
Pourquoi télécharger ce tutoriel CGI en PDF ?
Télécharger ce tutoriel fournit un exemplaire consultable hors ligne, structuré pour un apprentissage progressif et réutilisable lors d'un déploiement. Le PDF rassemble exemples de configuration, extraits de code et références officielles, et convient lorsque l'accès Internet est limité. Le format conserve la mise en forme et les blocs de code pour une consultation rapide lors d'exercices pratiques.
Fonctionnement du programme externe CGI
- Le navigateur émet une requête HTTP vers le serveur.
- Le serveur HTTP reconnaît la ressource comme exécutable et invoque le programme externe.
- Le programme reçoit variables d'environnement et éventuellement
stdin, puis produit des en-têtes et le corps de la réponse. - Le serveur relaie la sortie au client et journalise l'échange pour diagnostic.
Ce cycle illustre le rôle du programme externe dans la chaîne de traitement et explique comment l'interprétation ou la compilation influence le comportement lors de l'exécution par le serveur. Le CGI opère au niveau de la couche Application (couche 7) du modèle OSI.
Installation et configuration du répertoire cgi-bin
Créer un répertoire dédié pour les exécutables facilite la gestion des permissions et l'audit. Sur un système Unix, placez les scripts dans /usr/lib/cgi-bin ou un répertoire équivalent et assurez-vous que le répertoire et ses fichiers ont des permissions appropriées. Un réglage courant pour le répertoire est chmod 755 : le propriétaire conserve les droits d'écriture et d'exécution, tandis que le groupe et les autres peuvent lire et exécuter. Des droits excessifs (par exemple 777) exposent le serveur à des risques d'écriture non autorisée.
Configuration du serveur Apache pour le CGI
La configuration d'Apache précise où et comment les scripts peuvent être invoqués. Les directives essentielles associées au répertoire dédié permettent d'autoriser l'exécution tout en limitant les possibilities de modification des fichiers. La directive AddHandler cgi-script .pl associe explicitement l'extension .pl aux scripts Perl, facilitant l'exécution d'exemples historiques en Perl.
Directives Apache essentielles
ScriptAlias: associe une URL à un répertoire physique dédié aux programmes.AddHandler cgi-script .cgi .pl: associe les extensions à l'exécution CGI.Options +ExecCGI: autorise l'exécution de scripts dans un répertoire.
# Exemple de configuration minimale
ScriptAlias /cgi-bin/ "/usr/lib/cgi-bin/"
AddHandler cgi-script .cgi .pl
Options +ExecCGI
AllowOverride None
Require all granted
Pour approfondir la norme, consultez la RFC 3875 et la documentation officielle d'Apache.
Débogage des scripts CGI : consultez systématiquement les journaux d'erreur d'Apache (error_log) pour identifier les erreurs de permission, les erreurs d'interpréteur et les problèmes d'en-têtes. Ajoutez des traces simples dans les scripts (écriture dans un fichier de log hors du répertoire public) et vérifiez les permissions de ce fichier pour éviter les messages d'erreur silencieux.
Sécurité et bonnes pratiques des scripts CGI
La sécurité repose sur plusieurs principes : validation stricte des entrées, limitation des privilèges et gestion fine des permissions. Avant tout déploiement, appliquez chmod 755 aux répertoires cgi-bin afin d'empêcher les modifications non autorisées tout en permettant l'exécution. Ne donnez pas d'autorisation d'écriture au groupe ou aux autres pour les scripts exécutables. En complément, écartez l'utilisation d'extensions non nécessaires, contrôlez les accès via le virtual host et limitez les variables d'environnement exposées aux processus.
Validez systématiquement les données utilisateur côté serveur : rejetez ou filtrez les entrées non conformes, évitez les injections de commandes et neutralisez les caractères spéciaux avant toute utilisation dans un appel système ou une requête SQL. Préférez l'exécution sous des comptes à privilèges restreints et appliquez le principe du moindre privilège.
Scripts interprétés vs Binaires compilés (C/C++)
Un exécutable compilé (C/C++) produit un binaire autonome lancé par le serveur HTTP ; il s'exécute sans interpréteur, offre souvent un démarrage plus rapide et contrôle précis de la mémoire, mais nécessite une étape de compilation et une gestion des builds. Un script interprété (Perl, Python, Bash) est lu à l'exécution par un interpréteur, facilite le prototypage et la portabilité du code. Le choix dépend des contraintes de performance, de maintenance et de déploiement sur l'infrastructure cible.
Pourquoi utiliser Perl pour vos scripts CGI ?
Perl reste un choix fréquent pour les scripts CGI historiques en raison de ses capacités de traitement de texte et de la disponibilité d'un interpréteur sur de nombreux systèmes Unix. Les points forts incluent la richesse des expressions régulières, la facilité d'analyse de chaînes et la présence de bibliothèques facilitant le parsing des paramètres. Pour les environnements où la maintenance legacy est importante, l'interpréteur Perl et les conventions existantes simplifient la reprise de code.
#!/usr/bin/perl
use strict;
use warnings;
print "Content-Type: text/html\r\n\r\n";
print "Bonjour
";
Exemple de shebang : il indique à l'OS l'interprétateur à utiliser pour lancer le script sous Unix.
Comparatif : Scripts CGI vs SSI
Les SSI sont adaptés aux inclusions simples sans exécuter un programme externe ; les CGI conviennent à la logique métier et aux accès aux bases de données. Le tableau ci-dessous synthétise les différences principales.
| Aspect | CGI | SSI |
|---|---|---|
| Complexité | Élevée : nécessite scripts, interpréteur et gestion des permissions. | Faible : directives intégrées au serveur, pas d'exécution externe. |
| Performance | Peut être lourde (fork par requête) sauf avec FastCGI. | Légère : pas de fork, idéal pour fragments statiques. |
| Cas d'usage | Formulaires, logique métier, accès aux bases de données. | Inclusions de fragments (en-têtes, menus, dates). |
Exemples de directives SSI :
#include— inclure un fichier ou le résultat d'une commande.#echo— afficher une variable d'environnement ou une chaîne.#config— configurer le comportement des SSI (par exemple le delimiters).
Architecture et flux de données CGI
Le cycle d'une requête implique navigateur, serveur web et programme exécuté. Le client envoie une requête HTTP ; si la ressource correspond à un script autorisé, le serveur invoque l'exécutable et fournit des variables d'environnement et, pour les méthodes POST, un flux stdin. Le script renvoie les en-têtes (dont Content-Type) puis le corps de la réponse. Cette logique s'applique à la couche application du modèle OSI et concerne le traitement des protocoles tels qu'HTTP.
Les variables d'environnement CGI indispensables
Rôle de SCRIPT_NAME et QUERY_STRING
SCRIPT_NAME indique le chemin du script tel que connu du serveur et sert à reconstruire des URL ou à effectuer du routage côté application lorsque plusieurs logiques sont regroupées. QUERY_STRING contient la chaîne de requête après le signe ? et permet d'extraire des paramètres sans recourir au flux stdin.
| Variable | Description |
|---|---|
QUERY_STRING | Chaîne de requête après le ? dans l'URL. |
REQUEST_METHOD | Méthode HTTP utilisée (GET, POST, ...). |
CONTENT_LENGTH | Longueur des données envoyées dans le corps (utile pour POST). |
CONTENT_TYPE | Type MIME des données du corps. |
REMOTE_ADDR | Adresse IP du client. |
SCRIPT_NAME | Chemin du script tel que connu du serveur. |
PATH_INFO | Informations supplémentaires fournies dans l'URL. |
SERVER_PROTOCOL | Version du protocole HTTP utilisée. |
SERVER_SOFTWARE | Identification du serveur web. |
Sécuriser l'exécution des scripts CGI sur Apache
Limiter l'exposition passe par la configuration et les permissions : évitez d'exposer des répertoires contenant des fichiers non vérifiés, appliquez des contrôles d'accès (requêtes par IP, authentification) si nécessaire, et désactivez les handlers d'exécution sur des répertoires publics. Testez les scripts dans un environnement isolé avant mise en production et surveillez les logs serveur pour détecter des comportements anormaux.
Différences entre scripts CGI et modules Apache
Les scripts CGI lancent un processus séparé pour chaque requête, ce qui offre simplicité et isolation mais peut engendrer une surcharge CPU et mémoire à fort trafic. Les modules Apache s'intègrent au serveur, évitent le fork par requête et permettent des performances supérieures, mais demandent une intégration plus complexe et des précautions supplémentaires en cas de bogues. Le choix se base sur les besoins : prototypage et isolation (CGI) versus performance et montée en charge (module).
Limites du CGI et évolution vers FastCGI
Le principal inconvénient du CGI classique est le fork d'un processus par requête, source de latence et de charge CPU élevée sous forte affluence. FastCGI conserve l'isolation des processus tout en réutilisant des processus persistants, réduisant le coût d'initialisation et améliorant le débit. La migration vers FastCGI est souvent privilégiée pour des applications nécessitant des performances supérieures sans renoncer à la simplicité du modèle CGI.
CGI vs FastCGI : Quelle différence ?
FastCGI maintient des processus durables qui traitent plusieurs requêtes, évitant la surcharge liée au fork systématique. En pratique, FastCGI améliore la latence et la consommation CPU pour des applications à trafic soutenu ; il demande toutefois une configuration plus poussée du serveur et de la gestion des processus.
cours sur le développement back-end
Références : RFC 3875 (CGI/1.1), documentation Apache. Mots-clés présents : Common Gateway Interface RFC, interpréteur Perl, permissions Unix chmod, répertoire cgi-bin, FastCGI.
