Summary

  • Der erste W3C-Arbeitsentwurf zu Server-Sent Events vom 23. April 2009 beschrieb EventSource: Eine Webseite empfängt fortlaufende Ereignisse über eine HTTP-Verbindung vom Server.
  • Ein Ereignis konnte eine id tragen. Nach einer gewöhnlichen Unterbrechung meldete der Browser seine gemerkte Kennung im Header Last-Event-ID; eine leere id löschte diese Position.

Der Börsenticker steht still. Vielleicht hat der Markt endlich beschlossen, fünf Minuten lang vernünftig zu sein. Wahrscheinlicher hat die Verbindung aufgegeben. Dann erscheint wieder eine Zahl. Sie ist neu, aber ihre Vorgeschichte fehlt: Welche Meldungen lagen zwischen der Zahl vor dem Ausfall und der Zahl danach? Genau dort beginnt die Geschichte von Server-Sent Events.

Im W3C-Arbeitsentwurf vom 23. April 2009 öffnet eine Webseite mit EventSource eine Adresse und hört zu. Der Server liefert eine HTTP-Antwort vom Typ text/event-stream. Der Browser liest deren Zeilen, fasst sie zu Ereignissen zusammen und übergibt sie dem Seitenskript. Eine offene Leitung wird so zur Folge einzelner Meldungen. Für den Moment, in dem diese Leitung abreißt, erhielt die Folge eine Nummerierung.

Die Börsendemonstration des Entwurfs ist angenehm unspektakulär. Drei data-Zeilen enthalten YHOO, +2 und 10; eine Leerzeile schließt den Block. Aus den drei Zeilen wird ein Ereignis, dessen Inhalt das Skript aufteilt und im Ticker anzeigt. Die Leerzeile ist das Satzzeichen der Leitung. Der Server kann weiterschreiben, während der Browser trotzdem weiß, wann eine Nachricht fertig ist.

Das zweite Beispiel liefert den eigentlichen Lesezeichen-Trick. Neben data: first event steht id: 1. Der Browser merkt sich die Eins. Bricht die Verbindung vor der nächsten Nachricht ab, enthält seine neue Anfrage Last-Event-ID: 1. Der Last-Call-Entwurf vom Dezember 2009 hielt an diesem Ablauf fest. Der Client kommt mit einer Seitenzahl zurück, statt am Schalter zu erklären, irgendwo gegen Ende des Kapitels den Faden verloren zu haben.

Aus der Seitenzahl muss jemand eine Fortsetzung machen. Hat der Server die vergangenen Ereignisse aufbewahrt, kann er ab dieser Stelle eine passende Folge wählen. Hat er nur die jüngsten Meldungen, muss er anders reagieren. Wie lange ein Archiv reicht, wann eine Sitzung endet und was ein veraltetes Lesezeichen bedeutet, sind Entscheidungen des Dienstes. Der Browser kennt den letzten Empfang. Der Server kennt seine eigenen Unterlagen. Das Protokoll schafft den Ort, an dem sich beide Kenntnisse treffen.

Der Entwurf erlaubt auch, das Lesezeichen wegzuwerfen. In seinem Beispiel folgt später ein id-Feld ohne Wert. Es setzt die gemerkte Kennung auf leer; beim nächsten Verbindungsaufbau fehlt dann Last-Event-ID. Das kann sinnvoll sein, wenn der Ticker von einer Handelsrunde in die nächste wechselt. Die Nummer von gestern muss nicht zum Startkommando für heute werden. Eine so kleine Regel verhindert, dass eine alte Position ewig durch neue Sitzungen wandert.

Eine Zeile mit einem Doppelpunkt am Anfang ist ein Kommentar. Sie löst auf der Seite kein Ereignis aus. Die W3C-Empfehlung vom Februar 2015 nannte solche Zeilen als Möglichkeit, stille Verbindungen bei manchen älteren Proxys wachzuhalten. Sie beschrieb außerdem retry für die Wartezeit vor einem neuen Versuch und HTTP 204 No Content als Zeichen, dass der Browser mit den Versuchen aufhören soll. Ein Nachrichtenkanal braucht also ein gelegentliches Lebenszeichen und einen ordentlichen Feierabend.

Die W3C-Publikationsgeschichte führt vom Arbeitsentwurf 2009 über einen Candidate-Recommendation-Schnappschuss 2012 zur Empfehlung 2015. Der Kern blieb bemerkenswert sparsam: Textzeilen für Ereignisse, ein optionaler Bezeichner für die Stelle im Strom, ein neuer HTTP-Request nach der Unterbrechung. Der Browser erhielt genug Erinnerung, um eine präzise Frage zu stellen. Die Antwort blieb Aufgabe des Dienstes, der die Nachrichten tatsächlich besitzt.

Web Workers lösen eine andere Unhöflichkeit des Browsers. Sie verlegen eine lange Berechnung aus dem Bereich, in dem die Seite auf Klicks reagiert. EventSource transportiert Nachrichten von einem Server und trägt nach einem Verbindungsabbruch die letzte empfangene Position zurück. Einmal geht es darum, wer rechnet; hier darum, wer sich an die Reihenfolge erinnert. Der Ticker braucht keine große Philosophie. Er braucht eine brauchbare Nummer.