Server-Sent Events
Die wichtigsten Befehle zum Merken
curl -N— Streamingdaten ohne curl-Ausgabepuffer anzeigen.curl -i— Antwortheader und damit den Streamtyp sichtbar machen.
Befehle und Optionen
| Option | Bedeutung |
|---|---|
-iN |
Antwortheader (-i) mit ungepufferter Ausgabe (-N) kombinieren. |
--max-time 10 |
Die Beobachtung nach zehn Sekunden beenden. |
-H 'Accept: text/event-stream' |
Den SSE-Medientyp anfordern; Anführungszeichen halten den Header zusammen. |
Der Header nennt eine Präferenz. Content-Type der Antwort zeigt das tatsächlich gelieferte Format.
Die entscheidenden Konzepte
1. SSE hält eine HTTP-Antwort für Aktualisierungen offen
Server-Sent Events (SSE) überträgt Aktualisierungen vom Server zum Client über HTTP. Die Browser-API EventSource verwaltet dieses Muster. Der Server hält die Antwort offen und liefert verfügbare Ereignisse.
Der Stream ist einseitig. Der Client kann separate HTTP-Anfragen zurücksenden, aber keine Anwendungsnachrichten in Gegenrichtung innerhalb derselben Antwort. Das unterscheidet SSE vom bidirektionalen WebSocket-Kanal.
2. Textframing kennzeichnet vollständige Ereignisse
SSE verwendet UTF-8-Text mit Medientyp text/event-stream. Felder wie data:, event: und id: beschreiben Ereignisse. Eine Leerzeile schließt ein Ereignis ab. Mehrere Datenzeilen können gemeinsam dessen Inhalt bilden.
Eine Kommentarzeile mit führendem Doppelpunkt kann als Heartbeat dienen, ohne Benutzerereignis. Beliebige empfangene TCP-Stücke sind keine vollständigen SSE-Ereignisse. Parser müssen die Rahmung beachten.
3. Wiederverbindung braucht serverseitige Fortsetzung
EventSource kann nach Unterbrechung neu verbinden. Ereignis-IDs erlauben dem Client, über Last-Event-ID seine letzte empfangene Kennung mitzuteilen. Ein retry:-Feld kann eine Wartezeit in Millisekunden vorschlagen.
Die Kennung selbst speichert keine Historie. Der Server braucht aufbewahrte Ereignisse oder eine andere Wiederherstellung. Duplikate und überschrittene Aufbewahrungsfenster benötigen Anwendungslogik. Wiederverbinden ist keine automatische Exactly-once-Zustellung.
4. Puffer und Leerlaufregeln können Updates verzögern
Eine Anwendung kann sofort senden, während ein Proxy puffert oder eine Zwischenstation eine ruhige Verbindung schließt. Flush-Verhalten und passende Zeitgrenzen zählen entlang des ganzen Pfads.
Curl ändert mit no-buffer nur seinen eigenen Ausgabepuffer. Es zwingt weder Server noch Proxy zum Flush. Ein offener ruhiger Stream kann gesund, gepuffert oder blockiert sein. Entscheidend ist das erwartete Endpunktverhalten.
Ein kleines Beispiel
Optional: Verwende den vorhandenen lokalen SSE-Endpunkt. Der Befehl beobachtet nur und erstellt keinen Producer.
curl -iN --max-time 10 -H 'Accept: text/event-stream' http://127.0.0.1:8080/eventsLies HTTP-Status und Content-Type vor den folgenden Zeilen. Suche vollständige Ereignisse mit Leerzeilentrennung und unterscheide Daten von Kommentaren. Eine HTML-Fehlerseite wird durch den Accept-Header nicht zu SSE.
Nach zehn Sekunden kann curl trotz gültiger Ereignisse mit Timeout enden. Das Limit beendet absichtlich einen sonst laufenden Transfer. Curl zeigt Rohtext und implementiert hier weder EventSource-Wiederverbindung noch Ereignisdispatch.
Keine Ereignisse beweisen in diesem Zeitfenster keinen Fehler. Ohne Listener zeigt Connection Refused die fehlende Voraussetzung. Dateien und Hintergrundprozesse bleiben nicht zurück.
Merke dir: SSE überträgt gerahmte Ereignisse in einer HTTP-Antwort. Rechtzeitige Anzeige und zuverlässige Fortsetzung brauchen zusätzliche Regeln.