Dans cette dépêche, nous allons faire un tour d’horizon de différentes manières de communiquer avec un serveur depuis une application Web, avec un petit peu d’histoire, avant de rentrer plus profondément dans le fonctionnement des WebSockets, que nous allons démystifier. Nous digresserons ensuite à propos de la gestion (problématique) des requêtes longues et de HTTP 2 avec Apache, et nous discuterons d’une manière de limiter la casse. La dépêche contient quelques morceaux raisonnables mais l’absurdité est latente.

Supposons que nous ayons une application Web qui a besoin de recevoir des évènements du serveur pour voir si quelque chose s’est passé. À tout hasard, un jeu de société en ligne. Ce jeu a besoin d’envoyer les coups des joueurs et joueuses, et de recevoir les coups des autres.

Le serveur ne peut pas contacter le navigateur. Celui-ci est peut-être derrière un pare-feu, et de toute façon il n’y a pas de méthode pour cela. Le modèle du web, c’est une requête HTTP de la part du navigateur, et le serveur sert cette requête. Et puis, à la base, une requête = un chargement de page.

Mais des techniques sont apparues pour abuser de ce modèle, puis les standards se sont mis à intégrer des méthodes pour mener ces abus en toute sérénité.

Avez-vous déjà essayé de connecter une application web à du matériel spécifique ? Peut-être avez-vous réussi à récupérer la localisation d’un terminal par sa puce GPS, ou à activer une caméra… car ce sont des fonctionnalités qui sont prévues et intégrées dans les navigateurs (modernes). Mais imprimer directement sur une imprimante connectée en USB, ou piloter un périphérique branché au port série (comme un afficheur, une balance électronique de précision, etc.) ?

Probablement non… car, par définition, le contenu d’une page web ne doit pas accéder au matériel qui la fait tourner… C’est une base du cloisonnement et de la sécurité du WWW. Et c'est là que le EveConnector apporte une révolution à lui tout seul.