Summary

  • W3C's 23 April 2009 Server-Sent Events Working Draft described EventSource: a browser connection that receives a stream of server updates as events.
  • An event could carry an id. After an ordinary break, the browser could reconnect with that remembered value in Last-Event-ID; an empty id cleared the memory. The server controlled what to send in response.

A stock ticker that stops moving poses an excellent question and gives no answer. Did the market go quiet, did the wire go bad, or has the machine on your desk simply lost interest? Repeatedly asking a server for news is one way to find out, but it turns the browser into a nervous caller. A continuing stream offers a cleaner conversation. Then the wire snaps. What was the last update the page actually heard?

The Server-Sent Events Working Draft published by W3C on 23 April 2009 put an EventSource object on that line. A page opened a URL and listened for events; the server sent a response with the text/event-stream format. The browser parsed lines and dispatched messages as complete blocks arrived. This was still HTTP. Its distinctive trick was the little bit of memory carried from one connection to the next.

The draft used a stock example that could have come from a ticker's waste-paper basket: data: YHOO, then data: +2, then data: 10. Three lines became one event with three lines of data. The page's handler split them and updated the display. A blank line ended the event block. No elaborate envelope was required; the punctuation did the sorting. The same draft showed a colon-prefixed comment line that generated no event at all, a quiet note in the stream rather than another item for the reader.

Now give the first event an id: 1. The browser records the ID. If the connection disappears before the next event, its next request includes Last-Event-ID: 1. The server receives a bookmark rather than a vague complaint that the line went dead. The December 2009 Last Call draft kept that reconnect model. The page does not need to invent its own header, parse a handwritten resume token or rebuild the subscription from scratch each time a proxy sneezes.

The bookmark is useful precisely because it is small. It says what the client most recently saw. It does not put missing events into the browser by magic. A server that keeps a history can use the ID to choose a continuation; a server without one cannot replay a vanished update merely because the browser asked politely. The standard sets the exchange point. The feed operator decides whether old items exist, how long they remain available and what a reconnecting reader should receive.

The draft even supplies an escape hatch for the bookmark itself. In its four-block example, a second event carries an id field with no value. That empties the remembered ID. On the next reconnection the browser has no Last-Event-ID header to send. This is a small but consequential control: the source can say that the old position should no longer be used. A ticker that has rolled into a new session should not be forced to treat yesterday's mark as today's instruction.

Over the following years, the contract became a Recommendation. The W3C publication record traces the 2009 drafts through a 2012 Candidate Recommendation snapshot to the 3 February 2015 Recommendation. That final text specified ordinary reconnection after the stream closed, described a retry field for reconnection timing, and allowed an HTTP 204 No Content response to tell the client to stop trying. A colon-led comment could be sent periodically to keep some old proxy connections from timing out; the spec suggested roughly fifteen seconds as an example. It was an operator's nudge, not a charm against every intermediary.

The distinction from the newly published Web Workers story is concrete. A worker gives a page a separate place to perform long computation and a message boundary to bring the result home. EventSource gives a page an arriving sequence from a server and a way to tell the server where that sequence last reached the browser. Both use messages. The ownership problem is different: one asks who does the arithmetic; the other asks who remembers the place in a feed after the connection coughs.

The 2015 Recommendation also used named event fields, so a page could listen for more than an undifferentiated series of message events. The line-oriented format looked humble. That was part of its charm. A browser needed enough structure to recognize an event, its data, its optional name and its position; a server needed enough notice to decide what to deliver after an interruption. The stock ticker could go silent for a moment without demanding that both ends pretend it had never happened.