2026-09-29 · 6 min read · Rahul Chitturi
- http
- sse
- reliability
Server-Sent Events let a client keep a text/event-stream response open and reconnect after a drop. The browser stores the last event id field and sends it back as Last-Event-ID. The server is responsible for replaying anything the client missed after that id.
If the server never sets id, resume cannot work. If a proxy buffers the stream, the client may see a timeout instead of a clean reconnect.
Capture one event as bytes
Save the status, Content-Type, cache headers, and the raw event block including id, event, data, and the blank line that ends it. A JSON formatter will not show a missing trailing newline or a comment line that begins with a colon.
- Confirm the response is not buffered by a proxy.
- Record the Last-Event-ID sent on the next request.
- Note the retry field and the client timeout.
- Separate HTTP failure from an application error event.
Define what the identifier orders
The id must identify a position the server can resume from. A random UUID per connection does not help. A per-user monotonic position does, if the server stores events long enough to replay them.
Reconnects repeat the events after the last delivered id. Clients that apply side effects must tolerate a duplicate, because the browser may have processed an event and then lost the connection before the next id was stored.
Test drops, not only the happy stream
Use Flashman's JSON formatter for data payloads, the timestamp converter for event times, the UUID generator for synthetic positions in fixtures, and the URL parser for the stream request.
Kill the connection after an event with an id, after an event without one, and while a proxy is buffering. Verify replay, duplicates, an unknown Last-Event-ID, and an expired history window.