À cette étape, vous travaillerez uniquement sur le programme prog_server.cpp.

Il s'agit de réaliser les fonctions main() et http_dialog() selon les indications fournies en commentaire.
Tout ne sera pas traité dans l'immédiat, mais vous ferez juste :

Remarquez que la fonction http_dialog() utilise le type générique SocketType en lieu et place de SOCKET.
Il suffit pour l'instant de considérer ce type comme s'il s'agissait de SOCKET, et c'est effectivement le cas lors de l'appel depuis la fonction dialog_thread() ; ce type pourra devenir différent à la prochaine étape.
Les paramètres server et application de cette fonction ne servent pas encore mais seront nécessaires ultérieurement ; il faut les transmettre au thread avec cette formulation std::ref(server), std::ref(application)✍.

Vérifiez alors avec votre navigateur Internet que la visite de votre serveur permet bien d'obtenir l'affichage de la page HTML souhaitée ainsi que de l'icône sur l'onglet.

À cette étape, vous travaillerez à nouveau uniquement sur le programme prog_server.cpp.

Il s'agit maintenant de compléter les fonctions main() et dialog_thread() afin d'ajouter le support de HTTPS.

Pour cela, il est nécessaire d'ouvrir une seconde socket d'écoute TCP ; la précédente servira aux connexions en HTTP, la nouvelle servira aux connexions en HTTPS.
Il faudra bien entendu surveiller les deux sockets d'écoute TCP à la fois, afin de réagir aux connexions pouvant arriver sur l'une ou l'autre à n'importe quel instant.
Dans chacun des deux cas, la fonction dialog_thread() doit être appelée, mais un nouveau paramètre booléen doit maintenant lui être ajouté afin de distinguer les deux cas (HTTP ou HTTPS).

La fonction dialog_thread() exploitera ce paramètre supplémentaire pour déterminer si elle se comporte comme précédemment (HTTP) ou si un objet de communication SSL doit embarquer la socket (HTTPS).
Grâce au type générique SocketType, la fonction http_dialog() pourra être appelée en passant l'objet de communication SSL à la place de la socket de dialogue.
Remarquez qu'il ne sera pas nécessaire de changer quoi que ce soit au code source de la fonction http_dialog()✍.

En consultant le bas du fichier server.hpp, vous constaterez qu'un contexte pour SSL est créé ; puisqu'il doit jouer le rôle de serveur, il est nécessaire de lui fournir un certificat et la clef privée qui lui est associée (voir les commentaires pour la génération de tels fichiers).
C'est la fonction membre make_ssl() tout en haut du même fichier qui demande à ce contexte de créer un objet de communication SSL pour embarquer la socket.

Avec votre navigateur Internet, visitez votre serveur en précisant le protocole https:// et le port que vous avez choisi à cet effet.
Il est très probable que le navigateur signale une anomalie concernant le certificat qu'il reçoit de votre serveur.
C'est tout à fait normal ici puisque ce certificat a été généré de manière fantaisiste, juste pour le propos de l'exercice.
Comme vous le voyez au bas du fichier server.hpp, ce certificat est auto-signé, et concerne le common-name localhost.
Contentez-vous ici d'autoriser exceptionnellement votre navigateur à exploiter ce certificat✍.

Vous devriez alors constater que la visite de votre serveur en HTTPS permet d'obtenir l'affichage de la page HTML souhaitée ainsi que de l'icône sur l'onglet.
Assurez-vous également du fait que votre navigateur peut tout aussi bien continuer à solliciter votre serveur en HTTP.

À cette étape, vous travaillerez à la fois sur le programme prog_server.cpp et sur le code JavaScript de client.html.

La fonction http_dialog() doit maintenant être complétée pour recevoir des requêtes “POST /msg”.
Chaque message ainsi obtenu sera confié à la fonction handle_http_message() qui produira la réponse que vous devrez renvoyer pour une telle requête.
Vous devez compléter la fonction handle_http_message() afin de transmettre le message reçu à l'application et produire depuis l'application la réponse à renvoyer.

Remarquez que la fonction handle_http_message() commence par acquérir un accès exclusif à l'application.
En effet, plusieurs threads assurant le dialogue avec les clients sont susceptibles de solliciter l'application à l'occasion de la réception d'un tel message.
Le verrou ainsi obtenu vous assure que pendant la durée d'exécution de cette fonction elle est bien la seule à intervenir dans l'application (les autres attendront un peu, éventuellement).

Pour l'instant, le fichier client.html ne contient pas le moyen de produire et d'exploiter ces requêtes “POST /msg”.
Des commentaires au niveau des fonctions APPLI.setup_channel et APPLI.to_server, dans le code JavaScript fourni, vous guideront et il faudra vous inspirer de TopDir/httpAppli.html dans le sujet L09_HttpServer.
Il ne s'agit ici que de communication textuelle ; ne vous souciez donc pas de ce qui concerne la communication binaire.

Désormais, l'application doit fonctionner ; ouvrez la dans plusieurs fenêtres de navigateur, en HTTP et HTTPS.
La première chose à faire est de saisir un nom dans le champ “Me:” ; un message doit vous confirmer cette action dans tous les fenêtres.
Le champ “Say:” sert à envoyer un message à tous les participants ou à un seul en choisissant avec le menu “To:”.

Une observation attentive du comportement de l'application doit vous faire constater que lorsqu'une action est effectuée dans une fenêtre, un message de confirmation apparaît immédiatement dans celle-ci, mais que ce message peut mettre jusqu'à deux secondes à parvenir aux autres fenêtres.
Étudiez alors la fonction APPLI.ping() de client.html afin de comprendre ce qui distingue la réactivité entre la fenêtre qui provoque l'action et celles qui la constatent.
Quelle serait la conséquence de la réduction du délai dans la fonction APPLI.ping() ?

À cette étape, vous travaillerez à la fois sur le programme prog_server.cpp et sur le code JavaScript de client.html.

Pour réduire le délai constaté précédemment, il faut offrir au serveur un moyen de délivrer de l'information aux clients même quand ces derniers n'effectuent pas de requête.
Effectivement, en l'état, ces informations ne sont véhiculées que par les réponses aux requêtes des clients, et la fonction APPLI.ping() sert justement à créer une opportunité d'obtenir une telle réponse.
Le protocole websocket sert notamment à répondre à la problématique de l'envoi spontané d'information du serveur vers les clients sans même que ces derniers ne produisent de sollicitations répétées à cet effet.

La fonction http_dialog() doit maintenant être complétée pour accepter un passage au protocole websocket sur la réception des requêtes “GET /channel”.
Une fois ce changement de protocole accepté, la suite du dialogue via la websocket sera confiée à la fonction handle_websocket() avant sa terminaison.
Vous devez compléter la fonction handle_websocket() afin de réaliser une boucle qui réagit à chaque nouvelle réception d'un message par ce moyen.
L'intérêt essentiel ici est qu'après chaque réception par une telle websocket, des informations pourront être délivrées à toutes les websockets connues du serveur, et non seulement à celle qui vient d'être utilisée pour la réception.
L'acquisition d'un accès exclusif à l'application est bien entendu toujours nécessaire durant le traitement de la réception d'un message ; toutefois, l'attente de la réception d'un tel message ne doit pas monopoliser l'application.

Naturellement, le fichier client.html doit être modifié pour bénéficier de ce nouveau moyen de communication.
Des commentaires au niveau des fonctions APPLI.setup_channel et APPLI.to_server, dans le code JavaScript fourni, vous guideront et il faudra vous inspirer de TopDir/wsAppli.html dans le sujet L09_HttpServer.
Il ne s'agit ici que de communication textuelle ; ne vous souciez donc pas de ce qui concerne la communication binaire.
Une page obtenue en HTTP utilisera “ws:” comme protocole websocket alors qu'une page obtenue en HTTPS utilisera “wss:”.

De nouveaux tests complets de l'application, en HTTP et HTTPS, doivent vous faire constater une très nette amélioration de sa réactivité.

Remarquez qu'en théorie la fonction APPLI.ping() ne devrait plus être nécessaire désormais, puisque les informations en provenance du serveur peuvent dorénavant être délivrées spontanément.
Toutefois, nous allons la conserver car dans le cas où les fenêtres des navigateurs resteraient calmes pendant un long moment, aucun message ne circulerait et les connexions pourraient être fermées (par le navigateur, le proxy...).
Puisque aucune garantie ne peut être donnée quant à la persistance des connexions, l'application s'appuie uniquement sur la date du dernier message reçu pour considérer que l'utilisateur de l'application est toujours en ligne.
La fonction APPLI.ping() permet alors, même à un rythme très faible✍, de signaler au serveur la présence de l'utilisateur.
Vous pouvez notamment améliorer la robustesse en envisageant une reconnexion dans le cas où la websocket serait fermée involontairement.