Back to the Catalog
real-time
http
networking
javascript

Server-Sent Events Deep Dive: The Event Stream Format

11 questions

The precise SSE wire format from the WHATWG HTML spec: comment/keep-alive lines, multi-line data, the dispatch rule, named vs default events, the id and retry fields, stopping reconnection, and the reverse-proxy buffering gotcha. The parsing behavior here is verified with a spec-faithful parser in Node.

Start

Questions

  1. Not answered. In an SSE stream, what does a line beginning with a colon (:) do?
  2. Not answered. A single SSE event contains two data: lines. How is the payload delivered to the client?
  3. Not answered. What part of the SSE wire format signals "this event is complete — dispatch it now"?
  4. Not answered. Your server sends events tagged event: price, but the client's onmessage handler never fires. Why?
  5. Not answered. Which statements about SSE field parsing are correct?
  6. Not answered. What does a retry: 10000 line do, and what's the constraint on its value?
  7. Not answered. An EventSource reconnects on its own after a drop. Which 2xx HTTP status should the server return on (re)connect to make it give up and stop reconnecting?
  8. Not answered. SSE works locally, but in production behind nginx the events arrive in big delayed bursts instead of one-by-one. Most likely cause and fix?
  9. Not answered. An event sets id: 42. The next event has no id: line. If the client reconnects after that second event, what Last-Event-ID does it send?
  10. Not answered. Which statements about EventSource reconnection are correct?
  11. Not answered. Why do SSE servers periodically send a comment line (e.g. : ping) even when there's no real data to deliver?