CGI : quand le serveur a appris à calculer sa réponse

C'est le geste fondateur de tout ce que l'on appelle aujourd'hui une application en réseau. Tant que le serveur se contente de servir des fichiers, deux visiteurs qui demandent la même adresse reçoivent forcément la même chose. À partir du moment où la réponse est produite par un programme, elle peut dépendre de ce que le visiteur a envoyé, de l'heure, du contenu d'une base de données. La page devient une fonction.

Le problème que CGI résout

Les serveurs de 1992 savaient déjà exécuter des programmes, chacun à sa manière. Le problème n'était pas la possibilité, c'était l'absence de convention : un script écrit pour un serveur ne fonctionnait pas sur un autre. CGI ne crée pas une technologie, il fixe un contrat entre deux logiciels qui ne se connaissent pas.

Ce que la convention définit

Les variables d'environnement

Le serveur dépose dans l'environnement du programme les informations de la requête : méthode employée, chemin demandé, type de contenu, adresse du client. Le programme les lit comme n'importe quelle variable système.

L'entrée standard

Quand la requête transporte un corps, par exemple les champs d'un formulaire envoyé en POST, le serveur le donne au programme par son entrée standard, exactement comme on passe un fichier à une commande en ligne.

La sortie standard

Le programme écrit sa réponse sur sa sortie standard : quelques en-têtes, une ligne vide, puis le contenu. Le serveur reprend ce texte et le renvoie au navigateur. Rien de plus.

Le trajet complet d'une requête

1. Le visiteur remplit un formulaire et valide.
2. Le navigateur construit une requête HTTP contenant les champs saisis.
3. Le serveur reconnaît que l'adresse demandée correspond à un programme et non à un fichier.
4. Il lance ce programme et lui transmet la requête selon la convention.
5. Le programme calcule, interroge éventuellement une base, écrit sa réponse.
6. Le serveur ajoute ce qu'il faut et renvoie le tout au navigateur, qui affiche la page.

L'autre moitié du dispositif : le formulaire

CGI décrit le côté serveur. Il fallait aussi un moyen normalisé de saisir et d'envoyer des données depuis la page : c'est ce que fixe HTML 2.0 en novembre 1995, avec l'élément de formulaire, les champs et les deux méthodes d'envoi. Le choix entre ces deux méthodes reste, trente ans plus tard, l'une des décisions les plus mal comprises de la construction web.

Une règle apprise à la dure

Une requête GET ne doit rien modifier. La règle semble théorique jusqu'en 2005 : cette année-là, un logiciel d'accélération de navigation se met à précharger les liens des pages pour gagner du temps. Les applications qui avaient placé leurs actions de suppression derrière de simples liens voient leurs données disparaître sans qu'aucun utilisateur n'ait cliqué. La leçon n'a pas vieilli : un lien se visite, un bouton agit.

Ce que CGI a coûté

La convention a un défaut structurel : chaque requête lance un nouveau processus. Sur un site consulté par quelques dizaines de personnes, cela ne se voit pas. Sur un site fréquenté, le coût de démarrage devient le premier poste de dépense. Toute l'histoire des serveurs d'application se lit comme une réponse à ce défaut.

• Garder le programme en mémoire entre deux requêtes, au lieu de le relancer.
• Intégrer l'interpréteur au serveur lui-même, pour éviter le passage par un processus séparé.
• Écrire directement le serveur dans le langage de l'application, ce que fera Node.js en 2009.