After a Server-Sent Events response drops, how does the client tell the server which events it already received?

## The round trip, in four steps A district warning console holds one Server-Sent Events response open against a catchment feed. Level readings and threshold crossings arrive as events. The link goes down for ninety seconds. Here is the whole resumption mechanism: 1. **The server labels.** Each event it dispatches carries an `id:` field whose value identifies that event in whatever store the events are read from. 2. **The client remembers.** As each event is dispatched the client copies the current id into its own last-event-ID state. This is a client-side value; nothing is acknowledged back to the server while the stream is healthy. 3. **The client re-opens.** After the reconnection delay, the client issues the same `GET` again — same URL, same `Accept: text/event-stream` — and adds one request header field, `Last-Event-ID`, whose value is the id it remembered, encoded as UTF-8. If its last event ID is empty, it sends no such field at all. 4. **The server decides.** Your handler reads that field, looks the value up, writes out the events that followed it, and then continues with live ones. Step four is the one the specification does not write for you. ## Who owes what | piece | direction | who requires it | |---|---|---| | `id:` on an event | server to client | nobody — events without an id are perfectly legal | | remembering the last id | inside the client | the specification, of a conforming client | | `Last-Event-ID` request field | client to server | the specification, whenever the remembered id is non-empty | | replaying from that value | inside the server | only you | Reading the table in the wrong direction is the classic error. `Last-Event-ID` is a **request** header field and never appears in the response; `id:` is a field inside the **response** body and is never sent by a client. And the client sends the header whether or not you ever intended to honour it — its presence proves nothing about whether replay works. ## What the client will not do for you The automatic behaviour ends at sending the field. In particular: - It does not detect a gap. A reconnect that resumes correctly and a reconnect that silently skips ninety seconds of readings look identical to the receiving application unless you say otherwise in the data. - It does not re-ask for events the server declines to replay, and there is no protocol-level way to demand them. - It does not negotiate how far back you can go. It sends one value; whatever you do with it is what happens. ## The silent-gap failure, and how to avoid shipping it The failure mode is not an error, and that is what makes it expensive. The console reconnects, events resume, dashboards tick, and the level trace for one gauge has a hole across exactly the interval a flood warning would have been raised in. Nothing logged an exception, because nothing failed. Two habits prevent it. First, **make the handler read `Last-Event-ID` on every request, including the first**, and treat its absence as "this client wants everything from now on" rather than as the normal case. Second, **make replay visible in the data**: a distinct `event:` name for replayed events, or a marker event before the live ones, so the receiving application can tell that it was caught up rather than merely connected. ## Ids the header can carry The value travels as a request header field value, which constrains it more than the body does. It is encoded as UTF-8 and it cannot contain a line break: a line ending is what terminated the `id:` field on the way out, so an id with an embedded newline was never expressible in the first place. A value containing a NULL character is ignored rather than stored, so it cannot come back either. Practically, keep ids short and printable — they ride in every reconnect request, from every client, for the lifetime of the feed. ## What this is not It is not an acknowledgement protocol: the client is not confirming receipt, and the server learns the value only when something has already gone wrong. It is not delivery guarantee machinery — nothing here makes an event exactly-once. And it is not the browser client's `error`-and-reopen behaviour, which is the same mechanism seen from the receiving application's side. On the wire there are only two moving parts: a field the server writes, and a request header field the client writes back.