Summary

  • Le premier projet de travail Server-Sent Events, publié par le W3C le 23 avril 2009, décrivait EventSource : une page reçoit des événements envoyés par un serveur sur une connexion HTTP.
  • Un champ id donnait un repère à l'événement. Après une coupure ordinaire, le navigateur pouvait reprendre contact avec l'en-tête Last-Event-ID; le serveur décidait ce qu'il renvoyait.

Le bandeau des cours s'immobilise. Pendant une seconde, on se dit que la Bourse a enfin appris la modestie. Plus probablement, la connexion vient de rompre. La question intéressante arrive juste après : lorsque le bandeau repart, quelle annonce doit apparaître en premier ? Une page qui écoute un flux a besoin de distinguer le dernier cours qu'elle a vu du dernier cours que le serveur a produit.

Le projet de travail du W3C daté du 23 avril 2009 proposait un objet EventSource. La page ouvrait une URL et installait un gestionnaire d'événements. En face, le serveur répondait avec un flux au format text/event-stream. Le navigateur lisait des lignes, les rassemblait en événements et les remettait au script de la page. L'allure était celle d'un télétype, avec moins de papier à ramasser sous la table.

L'exemple boursier du projet tenait sur trois lignes de données : YHOO, +2, 10. Une ligne vide fermait le bloc; le navigateur remettait au gestionnaire un seul événement contenant ces trois valeurs, séparées par des retours à la ligne. Le script pouvait alors actualiser le symbole, la variation et le cours. Cette grammaire volontairement mince comptait : le serveur écrivait des lignes, le navigateur savait à quel moment elles formaient un message complet.

Le projet montrait ensuite le geste décisif. Un événement contenant data: first event portait également id: 1. Le navigateur mémorisait ce numéro. Si la connexion tombait avant l'événement suivant, sa nouvelle requête annonçait Last-Event-ID: 1. La version « Last Call » de décembre 2009 conserva ce modèle de reconnexion. Le client arrivait avec un marque-page, ce qui vaut mieux que de taper à la porte en disant vaguement « j'ai raté quelque chose ».

Le marque-page ouvrait une décision côté serveur. Un service qui conservait les anciens événements pouvait retrouver la suite à partir du numéro reçu. La politique de conservation, le point de reprise et la manière de traiter une série abandonnée appartenaient à l'exploitant du flux. Le navigateur apportait son dernier repère; il ne reconstituait pas à lui seul les annonces absentes. Cette répartition est l'intérêt du dispositif. La mémoire du client reste légère et le serveur garde la connaissance de sa propre histoire.

Le même exemple réglait aussi le cas d'une mémoire à effacer. Un événement ultérieur avait un champ id vide. Ce champ vidait l'identifiant conservé; la prochaine reconnexion se faisait sans Last-Event-ID. On peut imaginer un service passant d'une séance de cotation à une autre : l'ancien numéro cesse alors d'être un bon point de départ. Le mécanisme ne figeait pas le lecteur à jamais sur la première série de chiffres rencontrée.

Le flux avait d'autres petites conventions utiles. Une ligne commençant par deux-points était un commentaire : le navigateur la lisait sans fabriquer d'événement pour la page. Le texte devenu Recommandation le 3 février 2015 suggérait d'envoyer périodiquement un tel commentaire pour éviter que certains anciens mandataires ferment une connexion trop longtemps silencieuse. Il décrivait aussi le champ retry, qui influençait le délai avant une nouvelle tentative, et la réponse HTTP 204 No Content, qui demandait au client d'arrêter de revenir. Un flux vivant a parfois besoin d'un léger toussotement; il a aussi besoin d'une manière de dire bonsoir.

Le registre des publications du W3C situe ce travail : projets en 2009, instantané de recommandation candidate en 2012, recommandation en 2015. Le trait original demeure facile à voir. Un protocole de lignes suffit à transporter des nouvelles; un identifiant suffit à rouvrir la conversation au bon endroit, si le serveur a gardé de quoi répondre. Rien dans le charme du téléscripteur ne dispense l'exploitant de savoir ce qu'il a déjà dit.

Dans l'histoire voisine des Web Workers, les messages relient une page à un calcul qui travaille ailleurs dans le navigateur. Ici, ils arrivent d'un serveur au fil de l'eau. Le problème change de propriétaire : le calcul pose la question de la charge; le flux pose celle de la continuité après coupure. Le marché peut bien garder ses mystères. Le numéro du dernier événement, lui, doit être lisible des deux côtés de la ligne.