Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage.
Je m'appelle Nicolas Bernard Bernard et aujourd'hui, on va faire un bon en arrière,
un bon dans le temps et on va parler des scripts CGI.
Alors je vous mets un peu de contexte pour vous expliquer ce qui était le web avant
PHP.
En fait, au tout début des années 90, on avait des sites web qui étaient complètement
statiques.
Alors on avait du HTML, parfois un peu de CSS.
Il n'y avait évidemment aucune logique côté serveur et même le JavaScript n'arrive
qu'à partir de 95.
Donc c'est impossible par exemple d'afficher un message personnalisé ou même juste de
traiter un formulaire.
Et c'est là qu'arrive une technologie qu'on appelle CGI pour Common Gateway Interface
et qui est tout simplement un protocole qui a été inventé entre 91 et 93 et qui permet
un serveur web.
Alors là, on n'a même pas encore Apache.
Je crois qu'à Apache, c'est pareil, c'est 95.
Donc on a HTTPD qui a été créé par Tim Berners-Lee et ensuite on a NCSHTPD qui sont des ancêtres
de serveur web et ce protocole CGI va permettre à un serveur web d'exécuter un programme
à chaque requête et d'envoyer le résultat au navigateur.
Donc c'est la première fois que dans le web, on commence à pouvoir générer des pages
vivantes, des pages dynamiques.
Alors c'est quoi un script CGI exactement ?
En fait, un script CGI, c'est simplement un programme qui s'exécute côté serveur
et qui est déclenché par une requête HTTPD.
Alors il peut être écrit dans quasiment n'importe quel langage.
À l'époque, un des plus courants s'épeule mais on a aussi des scripts en C quand il
y a besoin de performance.
Ça peut être du piton, du bâche, etc.
Comment est-ce que ça se passe ?
Eh bien, quand un utilisateur accède à une URL, par exemple Hello World, le serveur
va aller chercher le programme, donc Hello-world.c, il va lire les variables d'environnement
puisque là il faut se dire que toutes les données qui sont envoyées par le navigateur
vont être transcrites dans des variables d'environnement.
Donc on va avoir request underscore method par exemple, donc il va être get, post, put,
etc.
On va avoir query string pour tous les paramètres du RL et il va envoyer aussi le corps de la
requête, par exemple pour une méthode post.
Eh bien, il va la passer au programme par l'entrée standard, l'interface de l'entrée
standard.
Et donc notre script ou notre binaire, eh bien il va traiter ces données, il va en faire
ce qu'il veut avec et puis il va renvoyer d'abord une requête, une requête, pardon,
un header dans la sortie standard, par exemple content type text slash html pour dire qu'il
va renvoyer du html et il va renvoyer dans la sortie standard le contenu de la requête
par exemple, un h1 avec Hello World.
Donc voilà, grosso modo, c'est ça le concept de CGI, c'est qu'on a un script ou un binaire
qui va récupérer, donc il va être appelé depuis une requête HTTP, qui va récupérer
les données depuis les variables d'environnement qui lui sont passées par le serveur web et
simplement renvoyer tout ça dans la sortie standard.
Alors on a un dossier spécifique, notamment sur Apache pour bien stocker tous les scripts
CGI et ce dossier il s'appelle CGI-bin pour CGI binary.
Donc c'est l'endroit vraiment où le serveur web, il va autoriser l'exécution des programmes
et pas ailleurs.
Dans ce dossier, les binaires ou les scripts peuvent être exécutés, tout ce qui est ailleurs,
que ce soit html, des images, du CSS, des fichiers, peu importe, ils sont servi en
lecture simple, c'est à dire qu'ils sont renvoyés au navigateur web et le navigateur
web soit il va décider de les télécharger ou de les afficher, etc.
Alors là il y a une petite confusion qu'on peut assez facilement faire parce que comme
ce dossier il s'appelle CGI-bin, on pense que seulement il stockait des binaires et que
seulement des binaires peuvent être exécutés.
Alors non, évidemment si on a des binaires qui sont compilés par exemple depuis C, C++,
etc., ça va fonctionner tant que ces binaires récupèrent les informations avec le format
du protocole CGI, mais n'importe quel script exécutable comme je l'ai dit, Perl, Piton,
Bache, PHP même, et bien tant qu'ils ont le fichier à les droits d'exécution et que la
première ligne du fichier, c'est un HatchBang, donc dies.exclamation, et qu'ensuite on déclare
quelles interpréteurs doivent être utilisées pour interpréter le reste du fichier, ça va
permettre au serveur web d'exécuter ce script et de lui envoyer les bonnes informations,
donc de créer un processus et d'envoyer les informations comme on a dit avant.
Alors c'est vrai qu'aujourd'hui des scripts CGI, on en voit quasiment plus,
à part sur des vieux projets legacy, et d'ailleurs si vous regardez sur Apache,
aujourd'hui les scripts CGI sont pas activés par défaut. Donc par exemple avec Apache,
il faut activer à la main le module mod underscore CGI et ajouter donc une configuration avec la
liste également de toutes les extensions de fichier qui va être autorisée à exécuter comme
étant des scripts CGI. On a même des serveurs web qui ne supportent pas nativement le CGI
classique, c'est le cas pour NGNX, lui il a été globalement conçu pour la performance et donc il
ne lance jamais de processus externes par requête, mais il y a possibilité quand même de le configurer
pour qu'il passe la main à un interpréteur notamment FastCGI, alors petit point rapidement sur
FastCGI, vous avez compris le concept de CGI, et bien FastCGI c'est à peu près la même chose
à deux grosses différences près, c'est d'abord qu'il ne lance pas un processus par requête,
il va gérer son ou ses processus, il va les garder en mémoire s'il y a besoin et envoyer les
données quand il y a une nouvelle requête, et surtout les données de cette requête ne sont
pas passées par des variables d'environnement, mais il y a un protocole spécifique où ça
envoie les données en binaire directement au processus par un autre moyen. Donc globalement
c'est pour ça qu'on dit FastCGI parce que c'est globalement beaucoup plus performant,
et donc sur EngineX vous pouvez configurer ce FastCGI pour qu'il gère des scripts,
notamment PHP, FPM, ça vous en avez peut-être déjà entendu parler, on ne va pas revenir trop dessus,
mais globalement PHP, FPM, c'est une évolution des CGI pour exécuter du PHP.
Et d'ailleurs pendant qu'on parle de PHP, j'imagine que certains d'entre vous vous
êtes dit mais évidemment qu'on pouvait faire des pages web dynamiques avec du PHP,
non puisque PHP n'existait pas encore, et d'ailleurs PHP est né grâce au CGI. En fait en 94 on a
Rasmus Lerdorf qui écrivait lui des scripts CGI en Perle, Puy-en-C etc. et notamment pour suivre
les visiteurs de son site. Et il a publié en fait ses outils fait en CGI, enfin avec le
Protocop CGI, il a publié sous le nom de Personal Homepage Tools et qui est simplement abrigé en PHP.
Si on résume PHP il est né d'un ensemble de scripts CGI et ensuite eh bien comme la
popularité qu'on lui connaît, eh bien ça a été intégré directement au serveur notamment
Apache avec mode PHP, puis PHP FPM dont j'ai parlé rapidement, donc aujourd'hui PHP il est soit
exécuté nativement directement dans le processus du serveur pour Apache, soit à l'extérieur du
processus mais qu'il y a un processus persistant avec PHP FPM. Et voilà c'est la fin de cet épisode,
j'espère que vous aurez appris quelque chose ou que ça vous aura fait remonter des vieux
souvenirs. Moi je vous donne rendez-vous la semaine prochaine pour un prochain épisode ou directement
évidemment sur code-garage.com pour retrouver tous nos articles de blog, tous nos épisodes de podcast
et toutes nos formations. Je rappelle aujourd'hui nos formations elles sont monotées en moyenne 4,8
étoiles sur 5 et aujourd'hui évidemment on a beaucoup de formations pour les juniors sur du
HTML, du CSS, du JavaScript, du React, du PHP etc mais on a aussi des formations un petit peu
plus spécifiques comme une formation sur le Kobol, sur la maîtrise et bien des concepts juridiques que
ce soit le RGPD mais aussi les licences logicielles etc et on a plein de choses pour un petit peu
tous les niveaux donc venez faire un tour et surtout pensez à laisser 5 étoiles au podcast sur
votre plateforme de podcast favoris et de parler du podcast autour de vous, envoyez un petit lien
du dernier épisode sur le slack de la boîte ça fait toujours plaisir et si ça peut faire progresser
tout le monde on est gagnant. Bonne semaine tout le monde, prenez soin de vous, salut !