La plupart des serveurs Web s’appuient sur un mécanisme standardisé pour exécuter du contenu dynamique. Ce mécanisme est la Common Gateway Interface, ou CGI. Ce n’est pas magique. Il s’agit d’une structure de dossiers et d’un ensemble de règles qui indiquent à un serveur d’arrêter de traiter le code comme du texte statique et de commencer à le traiter comme un programme exécutable.
La clé est un sous-répertoire spécifique nommé cgi-bin. Lorsque vous configurez un serveur Web, vous créez ce dossier à la racine de votre document. Le serveur est configuré pour surveiller ce répertoire de près. Tout fichier demandé à cgi-bin déclenche un comportement différent de celui d’une page HTML standard.
Au lieu de lire le fichier et d’envoyer son contenu brut à votre navigateur, le serveur exécute le fichier. Le résultat généré par cette exécution est ce qui est réellement livré au client. Cela permet au serveur d’exécuter du code à la volée, générant des réponses basées sur les entrées de l’utilisateur, les requêtes de base de données ou toute autre logique dynamique.
Les programmes stockés dans ce répertoire sont généralement soit des binaires compilés, comme ceux produits par un compilateur C, soit des scripts interprétés. Un langage domine cet espace : PERL. Il constitue l’épine dorsale des scripts CGI depuis des décennies car il gère le traitement de texte et l’interaction avec le serveur avec une facilité remarquable.
Prenons un exemple concret. Vous tapez cette URL dans votre navigateur : https://www.howstuffworks.com/cgi-bin/search.pl.
Le serveur voit le chemin. Il reconnaît que search.pl se trouve dans le dossier cgi-bin. Il ne vous envoie pas le code source. Il exécute search.pl. Le script PERL traite la requête (éventuellement en interrogeant un index de recherche) et renvoie le résultat HTML. Votre navigateur affiche ce résultat. Le code source ne touche jamais votre écran.
Voulez-vous essayer vous-même ? C’est possible, mais vous avez besoin de deux choses.
Tout d’abord, vous devez connaître un langage de programmation adapté à CGI. C et PERL sont les standards traditionnels. Vous devez comprendre comment générer des en-têtes HTTP et gérer les entrées du serveur.
Deuxièmement, vous devez accéder à un serveur Web prenant en charge l’exécution CGI. Si vous utilisez un service d’hébergement Web payant, vous disposez probablement déjà de cette fonctionnalité. La plupart des plans d’hébergement partagé incluent le support CGI par défaut. Consultez la documentation de votre fournisseur d’hébergement pour confirmer. Vous devrez peut-être télécharger vos scripts spécifiquement dans le répertoire cgi-bin.
Si vous n’avez pas de compte d’hébergement, vous pouvez installer un serveur Web sur votre ordinateur personnel. Cela vous donne un contrôle total. Vous pouvez expérimenter différentes configurations et déboguer les erreurs en temps réel. C’est plus compliqué que d’utiliser un service hébergé. Vous devez gérer vous-même le logiciel du serveur, la sécurité et les autorisations. Mais la courbe d’apprentissage est abrupte et utile. Vous comprendrez exactement comment fonctionne le Web sous le capot.
Cette configuration fonctionne car il est explicitement demandé au serveur de faire confiance et d’exécuter le code dans ce dossier spécifique. En dehors de cgi-bin, le serveur traite les fichiers comme des données statiques. A l’intérieur, ce sont des programmes. Cette distinction est ce qui rend les applications Web dynamiques possibles.
Le serveur exécute le programme et envoie la sortie au navigateur. Le code source reste caché.
Est-ce la manière la plus moderne de créer des applications Web ? Non. Les frameworks modernes utilisent souvent des architectures différentes. Mais CGI a établi le modèle. Cela a prouvé que les serveurs pouvaient exécuter des programmes externes pour générer du contenu. Chaque site dynamique que vous visitez aujourd’hui retrace sa lignée jusqu’à cette structure de répertoires simple.
La frontière entre le contenu statique et dynamique est définie par la configuration du serveur. Le **
