ENIB S7-CRS L09_HttpServer

{} Serveur TCP multi-threads

Tout au long de ce sujet, nous travaillons sur le programme prog_http_server.cpp.

Nous reprenons ici la démarche qui consistait à expérimenter “à la main” le dialogue selon le protocole HTTP, mais en jouant cette fois-ci le rôle d'un serveur qui sera sollicité par un client standard.
Nous réutilisons alors la commande ncat de cette façon $ ncat -C -4 -l numéro_de_port ↵ pour qu'elle écoute sur le port TCP indiqué (arbitraire >1024).
Lorsqu'une connexion sera établie sur ce port, le comportement sera le même que dans le cas du rôle client (saisie→envoi, réception→affichage).
Dans ce mode de fonctionnement, ce programme interactif n'accepte qu'une seule connexion, dialogue avec le client et se termine ; il ne sert qu'à expérimenter le rôle de serveur.
La connexion proviendra du navigateur habituel (connexion à localhost sur le port choisi) : $ firefox http://localhost:numéro_de_port/ceci/cela ↵ Vous devriez alors voir la requête du navigateur apparaître dans le terminal de la commande ncat : sa première ligne qui demande la ressource, les lignes d'options et la ligne vide de fin d'en-tête.
Il vous faut maintenant produire la réponse du serveur en la saisissant dans le terminal de la commande ncat (consultez attentivement les exemples du document Memo_HTTP.pdf).
Une première ligne indique que la requête est satisfaisante et donnera lieu à une réponse : HTTP/1.1 200 OK Pour faire simple, nous ne fournirons qu'une courte réponse au format HTML.
Nous indiquons donc que nous fermerons la connexion après cette réponse : Connection: close et que son contenu est du texte formaté en HTML (afin que le client sache comment interpréter la séquence d'octets qu'il obtiendra après l'en-tête) : Content-Type: text/html Nous saisissons la ligne de texte vide qui signifie la fin de l'en-tête de la réponse HTTP : ↵ et nous fournissons enfin le contenu utile (la courte page HTML) : <!DOCTYPE html> <html><head> <meta charset="utf-8"> </head><body> <hr>This is my first reply!<hr> </body></html> Ctrl d que nous terminons comme convenu par la fin-de-fichier.
Ceci doit provoquer l'affichage dans le navigateur de cette courte page au format HTML (interprétation des lignes, de l'italique, du gras...).

Cette expérimentation préalable illustre donc la manière dont notre programme serveur HTTP devra se comporter.
Il s'agit avant tout d'un serveur TCP semblable à ceux que nous avons déjà réalisés ; nous adopterons ici encore l'architecture multi-threads.

En complétant le point

{A}

du programme fourni, vous créerez la socket d'écoute TCP associée au port choisi en ligne de commande.
La fonction dialogThread() exécutée par le thread suite à l'acceptation d'une connexion reprend la forme que nous avons déjà utilisée pour nos précédents serveurs TCP.
Pour l'instant cette fonction ne fait aucun traitement utile et se termine immédiatement.
En l'état, il ne s'agit donc que d'un serveur TCP inutile qui déconnecte immédiatement les connexions qu'il accepte.

Documentation utile :

Memo_HTTP.pdf
std::thread
crs::socket() → man 2 socket
crs::bind() → man 2 bind
crs::listen() → man 2 listen
crs::acceptfrom() → man 2 accept

{} Échange requête/réponse HTTP minimal

Maintenant que notre serveur TCP est en place, nous abordons le dialogue en HTTP à proprement parler.
Comme nous l'avons vu lors de l'expérimentation préalable, dès que la connexion est établie, le serveur reçoit la requête HTTP du client.

En complétant le point

{B-1}

du programme fourni, nous recevons ligne par ligne l'en-tête de la requête HTTP en s'arrêtant à la ligne vide qui en marque la fin.
Cette boucle de lecture d'en-tête HTTP est assez similaire à celle que nous avions utilisée lors de la réalisation d'un client HTTP.
Toutefois, ici nous ne nous contentons pas de consommer aveuglément les lignes en en ignorant le contenu ; il nous faut au contraire en extraire les informations qui seront pertinentes pour produire la réponse.
Il s'agit de la méthode HTTP (GET, POST...) et de la ressource demandée sur la première ligne, et de l'option Connection: pour savoir si le client nous demande de fermer la connexion après notre réponse (si close n'est pas réclamé en HTTP/1.1 alors keep-alive représente le choix par défaut ; la même connexion sera réutilisée pour plusieurs requêtes/réponses).
D'autres champs de l'en-tête seront extraits de même façon✍ pour une utilisation ultérieure (voir les commentaires du code source).
N'hésitez pas à afficher les lignes de l'en-tête pour visualiser la requête formulée par le client.

Désormais, nous pouvons envisager de produire la réponse.
Nous commençons d'emblée par le cas qui signale que la ressource demandée ne pourra pas être délivrée !
Ce sera la seule réponse possible à cette étape mais ce deviendra le cas par défaut lors des étapes ultérieures.
Juste avant le point

{B-2}

nous préparons le document qui constituera le contenu de la réponse ; il n'est pas du tout question ici de protocole HTTP mais juste d'un message en HTML lisible par l'utilisateur du navigateur (ce n'est qu'un exemple similaire à ce que nous avons utilisé lors de l'expérimentation préparatoire avec la commande ncat).

Maintenant que le contenu de la réponse est connu, nous pouvons préparer un en-tête HTTP qui annoncera notre réponse au client.
Le point

{B-2}

du programme fourni est consacré à cet en-tête de réponse.
Puisqu'il s'agit de signaler un échec, nous nous contenterons comme première ligne d'en-tête de : HTTP/1.1 404 Not Found L'option Connection: doit ensuite être précisée, ainsi que Content-Type: qui doit annoncer que notre document est un texte formaté en HTML et Content-Length: qui en indique la longueur.
Attention à ne pas oublier la ligne vide qui marque la fin de l'en-tête !
Puisque notre serveur HTTP pourra à terme être contacté par des clients HTTP de toutes sortes, il est recommandé de terminer les lignes de texte par

"\r\n"

plutôt que simplement

"\n"

au cas où un tel client fonctionnerait sous Windows (ce système code les fins de ligne avec ces deux caractères).
Il ne reste plus qu'à envoyer, dans la connexion qui nous relie au client, cet en-tête suivi du contenu préalablement préparé.

Pour tester cette version minimaliste de notre serveur HTTP, il suffit de le lancer de cette façon : $ ./prog_http_server numéro_de_port ↵ en choisissant arbitrairement le numéro de port (>1024).
Le navigateur pourra alors le solliciter : $ firefox http://localhost:numéro_de_port/ceci/cela ↵ Vous devriez constater que votre serveur reçoit bien la requête du navigateur et produit en réponse votre document HTML que le navigateur affiche.
Saisissez dans la barre d'adresse de votre navigateur diverses ressources (à la place de /ceci/cela) afin de constater que votre serveur distingue bien à chaque fois la ressource demandée.

En l'état, vous disposez d'un serveur HTTP minimal qui sait recevoir et interpréter correctement une requête d'un client pour lui fournir une réponse formulée correctement que ce dernier pourra recevoir et interpréter.
Remarquez que, par défaut, le navigateur ne réclame pas que la connexion soit fermée après la réponse ; la même connexion TCP est donc utilisée pour plusieurs échanges successifs.

Documentation utile :

Memo_HTTP.pdf
crs::recvLine() → man 2 recv
crs::sendAll() → man 2 send

{} Transfert de fichier

Nous cherchons maintenant à rendre notre serveur HTTP un peu plus utile en lui permettant de délivrer des documents préalablement préparés dans des fichiers ; ainsi, sa réponse ne sera plus systématiquement un message d'erreur.
Vous remarquerez qu'après la réception de l'en-tête de la requête HTTP, le code de notre programme contient des opérations sur des chaînes de caractères afin de déterminer quel fichier correspond à la ressource spécifiée dans la requête.

Juste avant le point

{C-1}

du programme fourni, nous vérifions que la ressource réclamée désigne bien un fichier accessible ; il est donc envisageable d'en transférer le contenu vers le client.
De plus, l'extension du nom de fichier en question est utilisée afin de deviner la nature des informations inscrites dans ce fichier (ce procédé est très discutable mais a le mérite d'être simple à réaliser).
Assurez vous d'avoir compris l'effet de ces opérations.

Il vous faut alors compléter le point

{C-1}

pour rédiger et envoyer un en-tête de réponse HTTP.
Nous nous apprêtons à délivrer l'information demandée donc la première ligne de cet en-tête doit contenir : HTTP/1.1 200 OK Pour les options, il suffit de s'inspirer de ce que vous avez fait pour le message d'erreur.
Il ne reste plus alors qu'à compléter le point

{C-2}

afin de recopier le contenu du fichier désigné vers la connexion TCP.

En l'état, vous obtenez un serveur HTTP très simple permettant de délivrer des documents préalablement préparés dans des fichiers.
La racine du site en question est matérialisée par le sous-répertoire TopDir de notre répertoire de travail.
Utilisez votre navigateur pour suivre les liens des divers documents proposés.
Vérifiez également qu'il délivre toujours son message d'erreur lorsque vous lui réclamez une ressource incorrecte.
Vous constaterez que le rendu des pages (légèrement) élaborées ne repose que sur de multiples requêtes simples (les images, les liens...) auxquelles votre serveur sait répondre ; tout le travail de mise en forme concerne le navigateur.
En effet, la communication d'informations par le protocole HTTP et la visualisation de documents HTML sont deux choses tout à fait distinctes.
Nous avons naturellement tendance à en faire l'amalgame puisque les navigateurs traitent de ces deux aspects, mais le protocole HTTP peut servir à délivrer des informations quelconques qui n'ont rien à voir avec l'affichage de documents (c'est un simple moyen de communication).
Beaucoup d'applications sont d'ailleurs prévues pour inter-opérer par ce moyen (notamment à cause des politiques de sécurité, voir le sujet précédent).

Documentation utile :

Memo_HTTP.pdf
crs::isFile() → man 2 stat
crs::access() → man 2 access
crs::sendAll() → man 2 send
crs::openR() → man 2 open
crs::read() → man 2 read
crs::close() → man 2 close

{} Liste du contenu d'un répertoire

Il est courant, si un répertoire ne contient pas de fichier index.html, qu'un serveur HTTP produise une page HTML qui affiche la liste du contenu de ce répertoire lorsqu'il fait l'objet d'une requête.
Nous nous proposons ici de fournir une telle fonctionnalité.

Si la ressource demandée ne désigne pas un fichier qui a pu être fourni par ce qui a été réalisé à l'étape précédente, alors il convient d'envisager le cas où cette ressource désigne un répertoire.
En complétant le point

{D}

du programme fourni, nous traitons ce cas.

Il s'agit à nouveau de produire une page HTML lisible par l'utilisateur afin de lui offrir des liens vers les éléments du répertoire en question. La démarche est très semblable à celle qui consistait à fournir un message d'erreur et doit être complétée par le point

{D}

qui produit et envoie l'en-tête de réponse HTTP annonçant ce contenu qui sera envoyé à la suite.

Testez votre serveur depuis votre navigateur afin de constater le bon comportement de cette fonctionnalité.
Votre navigateur doit non seulement être en mesure d'afficher la liste du contenu d'un sous-répertoire, mais doit également permettre de suivre les liens sur les éléments indiqués.

Cette étape ne consistait, somme toute, qu'en un simple travail de formatage du contenu transmis (des pages HTML ici) mais n'apportaient rien de nouveau à la manière de transmettre ce contenu en HTTP (très similaire à la première réponse 404).
Ceci illustre le fait que les quelques connaissances acquises en matière de communication HTTP sont directement applicables sans plus de complication à des sujets applicatifs variés (seul le contenu, spécifique à l'application, nécessite un traitement dédié).
Arrivé à ce point de l'exercice, et conjointement avec le sujet précédent qui traitait des clients, vous avez maintenant en main les quelques briques de base qui suffisent à réaliser des applications interagissant depuis des sites distants pour lesquels les communications directes sur des ports TCP ou UDP quelconques ne sont pas autorisées (l'usage de HTTP et est en général autorisé, éventuellement à travers un proxy).

Documentation utile :

Memo_HTTP.pdf
crs::isDir() → man 2 stat
crs::access() → man 2 access
crs::sendAll() → man 2 send

{} Échange de données applicatives par requêtes POST

Au delà de fournir un contenu préparé à l'avance, il est envisageable qu'un serveur HTTP soit intégré à une application spécialisée afin d'interagir avec un navigateur (qui sert alors d'interface graphique).
Pour illustrer ce propos, le lien HTTP application de la page principale de notre serveur délivre au navigateur un fichier HTML dont le code javascript provoque des échanges en HTTP avec le serveur et modifie l'affichage en conséquence.
Étudiez alors la fonction d'initialisation window.onload du fichier TopDir/httpAppli.html afin de constater la mise en place des moyens de communication (XMLHttpRequest) et leur usage (émission/réception).
Bien entendu, en l'état cette application ne fonctionne pas puisqu'il nous faut compléter notre serveur afin qu'il réagisse de manière appropriée aux requêtes spécifiques de cette application.

Cette application en javascript est susceptible d'envoyer des informations textuelles ou binaires sous la forme de requêtes POST.
Dans ces conditions, les données utiles sont transmises du client vers le serveur juste après l'en-tête de la requête qui doit indiquer grâce à l'option Content-Length: le nombre d'octets que le serveur devra extraire après la réception de cet en-tête.
L'application en javascript indique explicitement son intention réclamant la ressource /txt ou /bin lors de l'émission de sa requête POST ; il ne s'agit bien entendu que d'un choix applicatif particulier à l'exemple réalisé ici.

Afin de réagir aux sollicitations textuelles du client, nous traiterons en premier lieu la réception de requêtes POST /txt.
Le point

{E-1}

extrait et affiche la chaîne de caractères fournie par le client.
La réponse à fournir en

{E-2}

est, somme toute, très similaire à ce que nous avons réalisé jusqu'alors ; nous nous contentons simplement de préciser que nous renvoyons du texte brut.

De la même façon, nous traiterons le cas de requêtes POST /bin afin d'obtenir des données binaires en provenance du client.
Le point

{E-3}

extrait les octets attendus et suppose qu'ils constituent un tableau d'entiers ; bien entendu ceci est un choix applicatif ici et ces données binaires pourraient tout aussi bien avoir une toute autre signification.
Remarquez que, comme tout échange de données binaires, la question de l'ordre des octets entre les deux interlocuteurs se pose.
Le traitement qui suit (affichage et modification des entiers reçus) prend les précautions habituelles juste après la réception des données binaires et juste avant leur émission.
La fourniture de la réponse en

{E-4}

est une nouvelle fois très similaire à ce que nous avons déjà réalisé ; nous nous contentons simplement de préciser que nous renvoyons des données brutes.

Désormais, le lien HTTP application de la page principale de notre serveur doit faire apparaître dans le navigateur une application simpliste qui envoie un message textuel au serveur lors de son démarrage et des messages textuels ou binaires selon l'usage des boutons qu'il propose.
Les réponses que le serveur a fourni suite à ces messages sont affichés par l'application.

Documentation utile :

Memo_HTTP.pdf

{} Échange de données applicatives par websocket

L'étape précédente permet effectivement d'envisager des applications dans lesquelles le client et le serveur peuvent interagir pour un propos tout autre que l'affichage d'une page HTML ou d'une image par exemple.
Les données qu'ils s'échangent peuvent avoir une signification quelconque applicable à tout sujet applicatif.
Seulement, en l'état, l'échange est toujours à l'initiative du client ; le serveur ne transmet des informations au client que sur requête de celui-ci.
Il est bien envisageable de recourir à des astuces pour contourner cette limitation :

polling : le client sollicite régulièrement le serveur avec une requête insignifiante juste pour lui donner l'occasion de profiter de la réponse comme moyen pour le serveur de transmettre de l'information au client.
- Cette solution est très mauvaise car elle génère un énorme trafic inutile et n'autorise que des temps de réponse très médiocres.
long-polling : le client sollicite le serveur avec une requête insignifiante que ce dernier conserve ouverte jusqu'au moment où il aura une information à faire parvenir au client.
Il profite alors de la réponse laissée en suspens pour fournir cette information, et le client, dès la réception de la réponse, formule une nouvelle requête insignifiante afin d'offrir à nouveau au serveur une future réponse potentielle pour la prochaine information à transmettre.
- Cette solution, bien qu'assez compliquée à mettre en œuvre, est bien meilleure que le simple polling car elle ne génère pas énormément de trafic inutile et offre un temps de réponse raisonnable (dès que le serveur le décide il peut fournir une nouvelle information dans la réponse laissée en attente).
- Toutefois, elle implique malgré tout le surcoût d'un échange complet d'en-têtes HTTP (à produire et surtout à analyser) à chaque échange d'information, même s'il ne s'agit que de transmettre quelques octets utiles.

Les websockets ont été inventées pour palier les inconvénients évoqués ici.
Elles visent à offrir aux applications qui communiquent initialement en HTTP un moyen très efficace d'échanger des données applicatives de manière bidirectionnelle.
Il s'agit presque d'utiliser directement la connexion TCP sous-jacente, à un détail près toutefois : chaque message websocket forme un tout indivisible (comme les datagrammes UDP, et contrairement aux flux d'octets TCP).
Le protocole websocket prévoit donc pour chaque message un en-tête binaire extrêmement court et facile à analyser qui spécifie quelques propriétés du message, dont notamment sa longueur.
Pour accéder à ce nouveau protocole, le client HTTP demande au serveur d'abandonner HTTP au profit de websocket (il lui transmet notamment une clef) ; s'il accepte, le serveur répond avec un en-tête HTTP qui confirme le changement de protocole (et en retransmettant la clef modifiée), puis tout ce qui suit ce dernier en-tête ne concerne plus désormais que le protocole websocket.
Les fonctionnalités pour transformer la clef, émettre et recevoir des messages websocket sont également exposées ici par le fichier d'en-tête crsUtils.hpp (les envois et réceptions ne sont constituées que de quelques opérations de base sur les sockets TCP).
Ce site donne une description très pratique et suffisamment détaillée de tout cela.

Pour revenir à notre réalisation, il nous faut tout d'abord nous assurer du fait que la lecture de l'en-tête de la requête HTTP prenne bien en compte l'option Upgrade: qui sert à réclamer l'abandon de HTTP au profit d'un autre protocole, et l'option Sec-WebSocket-Accept: qui indique la clef produite par le client.
Lorsque notre serveur constate que le client à réclamé un basculement vers le protocole websocket, il nous faut intervenir au niveau du point

{F-1}

afin de confirmer au client le fait que ce changement de protocole aura bien lieu.

Puisque avec les websockets chaque nouvelle information transmise peut à tout moment provenir du client ou du serveur, nous explorons cette possibilité dans notre application simpliste.
À cette fin, nous utilisons l'appel std::select() non pas pour surveiller simultanément plusieurs communications mais pour bénéficier de la possibilité de spécifier un délai maximal lors de l'attente d'un message en provenance du client.
Ainsi, si au bout du délai spécifié aucun message ne parvient du client, notre serveur quitte son attente dans crs::select() ce qui lui donne l'opportunité d'envoyer lui-même un message au client de manière spontanée.

Arrivés au niveau du point

{F-2}

, crs::select() vient de nous promettre que la prochaine opération de réception sur la socket de dialogue ne sera pas bloquante.
Nous pouvons dès lors tenter l'extraction d'un message websocket : chaque message a bien entendu une longueur mais également un code qui en indique la nature.
Si rien n'est disponible c'est que la connexion TCP a été fermée par le client.

Si le code du message reçu indique qu'il s'agit d'un message textuel, alors nous pouvons nous contenter de l'afficher comme tel au niveau du point

{F-3}

.
À titre d'illustration d'une fonctionnalité applicative, nous pouvons décider que si le texte reçu est équivalent à "quit" alors nous pouvons mettre fin à l'application (donc aux échanges à travers cette websocket).
Si le code du message reçu indique au contraire qu'il s'agit d'un message binaire, alors, au niveau du point

{F-4}

, nous interprétons les octets obtenus comme un tableau d'entiers de 32 bits reçus en respectant l'ordre des octets du réseau.
Nous nous contentons ici d'afficher ces entiers.
Les points

{F-5}

{F-6}

traitent de messages spéciaux qui permettent de tester la connectivité et de réclamer la fin au dialogue.

Après avoir réagi à d'éventuels messages websocket reçus, les points

{F-7}

{F-8}

permettent au serveur d'envoyer spontanément des informations au client (sans que celui-ci ne le demande préalablement).
Il peut s'agir de texte ou de données binaires (en considérant une nouvelle fois l'ordre des octets du réseau).

Remarquez que lorsque nous décidons de quitter la boucle de dialogue websocket, il n'est pas question de continuer à exploiter la connexion pour poursuivre le dialogue en HTTP.
Nous quittons alors également la boucle de dialogue HTTP avec l'instruction break; comme si nous avions utilisé close comme mode de gestion de la connexion.

Une fois tous les points

{F-?}

du code correctement complétés, il devient possible d'exploiter le lien WebSocket application de la page principale de notre serveur.
Il délivre au navigateur un fichier HTML dont le code javascript provoque des échanges en websocket avec le serveur et modifie l'affichage en conséquence.
Étudiez alors la fonction d'initialisation window.onload du fichier TopDir/wsAppli.html afin de constater la mise en place du moyen de communication (WebSocket) et son usage (émission/réception).
Vous devriez constater que les boutons proposés provoquent bien un effet sur le serveur (comme dans le cas de l'application HTTP) mais qu'en plus le serveur délivre spontanément des messages au client (qui se contente de les afficher).

La solution technique présentée ici, reposant sur les websockets, est non seulement plus facile à réaliser que son équivalent en HTTP, mais est également bien plus efficace dans l'échange des messages car aucun en-tête HTTP ne doit plus être analysé.
La possibilité d'émettre spontanément des données depuis le serveur vers le client est un atout indéniable.
Imaginez par exemple un équipement délivrant des événements ou des mesures de capteurs sur lequel fonctionne un serveur semblable au notre : les informations sont transmises aux clients dès qu'elles apparaissent sur la plate-forme du serveur (sans avoir à mettre en place un coûteux mécanisme de scrutation).

{} Exécution de processus CGI

Cette partie complémentaire repose sur l'usage de notions de programmation système qui ont été abordées au début dans cet enseignement.
Il s'agit notamment d'exploiter les redirections d'entrées/sorties et le recouvrement de processus.

Nous proposons ici une fonctionnalité qui permet d'étendre encore le champ d'action de notre serveur HTTP.
Il s'agit de lui faire exécuter un programme externe dans un processus enfant qui produira le contenu devant être délivré au client.
Ce procédé est décrit ici :

https://en.wikipedia.org/wiki/Common_Gateway_Interface

Par convention, les programmes sont placés dans un sous-répertoire dédié à cet effet ("/cgi-bin/" ici).
Ce sont des fichiers exécutables (scripts, programmes compilés...) qui sont censés lire leur entrée standard et produire du contenu sur leur sortie standard.
Nos connaissances en matière de redirection d'entrées/sorties et de recouvrement de processus nous seront alors utiles afin qu'un tel programme utilise la connexion TCP qui relie le client et le serveur HTTP en lieu et place de ses entrées/sorties standards.

De tels programmes sont susceptibles de recevoir de l'information depuis le client après que l'en-tête de la requête soit reçu ; c'est le cas des requêtes selon la méthode POST (voir le document Memo_HTTP.pdf).
Dans ce cas, une telle requête doit contenir une option Content-Length: indiquant la quantité de données que le client envoie après l'en-tête.
Vérifiez tout d'abord que la réception de l'en-tête de la requête HTTP prend bien en considération cette option.
Celle-ci pourra alors être transmise ultérieurement au processus CGI afin qu'il consomme les données annoncées.

Lorsque la ressource demandée est bien un fichier exécutable du sous-répertoire "/cgi-bin/", le point

{G-1}

de notre programme doit commencer par rédiger et envoyer le début de l'en-tête de réponse HTTP.
Il ne s'agit en effet que du début de cet en-tête car la fin relève du processus CGI qui sera exécuté ; en particulier c'est ce dernier qui connaît la nature des données (Content-Type:) qu'il produira.
C'est donc le processus CGI qui enverra la fin de l'en-tête, avec sa ligne vide, et le contenu utile qui suivra.

Comme indiqué plus haut, le point

{G-2}

du programme fourni revient à utiliser un processus enfant afin que celui-ci opère des redirections d'entrées/sorties sur la connexion TCP avant d'être recouvert par le programme choisi.
Une connexion TCP est en effet bidirectionnelle et peut donc servir à la fois d'entrée standard et de sortie standard.
Il reste toutefois à transmettre quelques consignes au processus en question afin qu'il adapte son comportement en conséquence : il s'agit (pour faire simple ici) de la méthode, de l'URI et de l'option Content-Length: de la requête HTTP reçue.
Nous avons recours pour cela à des variables d'environnement ; ce sont des variables textuelles qui ont la propriété d'être conservées après une opération de recouvrement.
Ainsi, si le processus enfant initialise ces trois variables d'environnement avant le recouvrement, alors le nouveau programme exécuté dans l'enfant pourra consulter ces mêmes variables et retrouver leurs valeurs pour les interpréter.

En l'état, vous pouvez tester cette nouvelle fonctionnalité de votre serveur en suivant les liens dynamic page, GET form et POST form de sa page principale grâce à votre navigateur.
Vérifiez que le premier script est un simple programme shell qui invoque quelques commandes qui produisent dynamiquement du contenu (la date et la liste des processus notamment).
Vérifiez également que les formulaires (méthodes GET et POST) provoquent bien l'invocation d'un programme python qui réagit aux informations fournies par le client (l'utilisateur du navigateur ici).
Étudiez avec attention la transmission de ces informations par le client pour chacune de ces deux méthodes.

Le procédé utilisé ici permet d'étendre notre serveur quasiment à l'infini dans le sens où il suffit de le compléter avec de nouveaux programmes exécutables dédiés à la production dynamique de contenu quelconque.

Documentation utile :

Memo_HTTP.pdf
crs::sendAll() → man 2 send
crs::fork() → man 2 fork
crs::waitpid() → man 2 waitpid
crs::setenv() → man 3 setenv
crs::dup2() → man 2 dup2
crs::close() → man 2 close
crs::exec() → man 2 execve