SSE-Event-Viewer

Fügen Sie eine aufgezeichnete text/event-stream-Antwort ein und wählen Sie ein Event. Der Viewer liest Text, ohne eine Live-Verbindung aufzubauen.

Läuft lokal in deinem Browser

Kategorie ansehen: API-Entwicklung (15)

SSE-StreamtextDurch Leerzeilen getrennte text/event-stream-Frames einfügen

Protokoll-Frames ohne Verbindung prüfen

Fügen Sie eine erfasste text/event-stream-Antwort ein, um Felder und Dispatch zu prüfen. Authentifizierung, Reconnect, HTTP-Caching und Verbindungszustand gehören weiterhin in Client- und Servertests.

So prüfen Sie einen aufgezeichneten SSE-Stream

Fügen Sie eine aufgezeichnete text/event-stream-Antwort ein und klicken Sie auf Events parsen. Der Viewer zerlegt sie in Events und zeigt Name, die ID, die ein Browser melden würde, den Retry-Wert und die gefalteten Daten; gültiges JSON wird im Detailbereich dekodiert, und der ganze Stream lässt sich als NDJSON kopieren.

Das Parsen folgt den Regeln, die ein Browser auf einen EventSource-Stream anwendet: Ein Frame, der hier erscheint, wird auch im Client ausgeliefert, und ein hier verworfener Block wird auch im Browser verworfen. Alles läuft in der Seite: Es wird keine Verbindung geöffnet und kein eingefügter Text hochgeladen.

Fügen Sie die Aufzeichnung in das Textfeld für den SSE-Stream ein.

Klicken Sie auf Events parsen. Die Tabelle listet jedes ausgelieferte Event; ein Stream, der einen Block nie mit einer Leerzeile abschließt, erzeugt keine Events – genau wie eine abgebrochene Verbindung.

Klicken Sie auf eine Zeile, um die vollständigen Daten des Events samt dekodiertem JSON zu sehen.

Mit NDJSON kopieren nehmen Sie alle Events mit, mit Leeren setzen Sie den Arbeitsbereich zurück.

Feldregeln, IDs und Auslieferungszeitpunkt

Was der Parser liest

Feldnamen werden wörtlich verglichen: data, event, id und retry. Ein Leerzeichen nach dem Doppelpunkt wird entfernt, „data:x“ und „data: x“ haben also denselben Wert, während „data: x“ ein führendes Leerzeichen behält. Eine Zeile ohne Doppelpunkt ist ein Feldname mit leerem Wert, eine allein stehende Zeile „data“ hängt also eine leere Zeile an die Daten; unbekannte Felder werden ignoriert.

Jede data-Zeile wird mit einem Zeilenumbruch angehängt; die gefalteten Daten behalten diese Umbrüche und verlieren den letzten bei der Auslieferung. Kommentare beginnen mit einem Doppelpunkt und lösen nie ein Event aus; der Zähler zeigt, wie viele vorhanden waren.

IDs, Retry und Auslieferungszeitpunkt

Ein Event wird nur ausgeliefert, wenn eine Leerzeile den Block beendet. Der letzte unvollständige Block wird verworfen – das tut ein Browser mit einem Stream, der mitten im Event endet; ergänzen Sie die fehlende Leerzeile, wenn Sie ihn sehen wollen. Ein id-Feld setzt die letzte Event-ID sofort, ein späteres Event ohne id trägt denselben Wert, und ein leeres „id:“ löscht ihn. Eine ID mit NUL-Zeichen wird ignoriert. Nur der Eventname fällt auf „message“ zurück.

retry wird nur akzeptiert, wenn der Wert aus Ziffern besteht; die Kennzahl zeigt den zuletzt akzeptierten Wert, also die Wiederverbindungszeit, die ein Client für den Rest des Streams nutzt. Der Viewer misst nicht, wie lange der Server gebraucht hat oder ob eine Wiederverbindung tatsächlich stattfand.

Was diese Seite nicht tut

Der Viewer liest Text. Er öffnet keine EventSource-Verbindung, sendet keine Header, authentifiziert nicht, folgt keinen Weiterleitungen und testet nicht, wie ein Server unter Last reagiert; ob eine Aufzeichnung vollständig ist, kann er nicht wissen. Die JSON-Erkennung ist ein strikter Parse der gefalteten Daten, „data: [DONE]“ bleibt also Text, während „data: null“ als dekodiertes JSON zählt.

Die Tabelle zeigt die ersten 180 Zeichen jeder Datenzeile; Detailbereich und NDJSON-Kopie enthalten die vollständigen Daten. Lange Aufzeichnungen werden in der Seite geparst, eine sehr große Eingabe hängt also am Speicher des Geräts, nicht an einem Serverkontingent.