In a Server-Sent Events stream, what does a `retry:` field sent by the server tell the client to do?

## What a `retry:` line actually sets A Server-Sent Events feed is one HTTP response that the server never finishes. The client issues an ordinary `GET` with `Accept: text/event-stream`, the server answers `200 OK` with `Content-Type: text/event-stream`, and then writes events into the body for as long as the feed lasts. Because it is an ordinary response, it can end at any moment: a laptop lid closes, a radio link out to a river gauge drops in exactly the weather that made the feed worth watching, an intermediary decides a quiet response has been idle long enough. The client does not surface that as a failure and wait for your code to react. It re-opens the request by itself. `retry:` is how the server gets a vote on **when**. - The value is a delay in **milliseconds**. `retry: 15000` means fifteen seconds — not fifteen milliseconds, and not fifteen attempts. - It is a property of the stream as a whole, not of the event it happens to sit near, so it does not have to be repeated on every event. - It affects *when* a client returns, not *whether* it returns: the separate question of which responses tell a client to stop reconnecting altogether is not decided by this field. - The direction is fixed. The **server** writes `retry:`; the **client** obeys it. There is no client-to-server field of this name. ## Before the server says anything A client that has just opened a feed has no delay from you yet. The specification leaves the starting value to the implementation, and in practice it is a small number of seconds. That has two consequences worth thinking about for a district warning console: | situation | delay in effect | |---|---| | Stream opened, no `retry:` seen yet | the client's own implementation-defined default, typically a few seconds | | `retry: 15000` received | fifteen seconds, from then on | | `retry: 15000`, then later `retry: 2000` | two seconds — the most recent value wins | | Response drops and is re-opened | whatever value was last in effect carries over | First, if you never send the field you have accepted whatever the client chose, on every client type that connects to you. Second, because the value survives reconnects, sending it once near the top of the response is enough; you do not have to re-state it after every gauge reading. ## Choosing a number for a real feed The delay trades freshness against load, and both sides of that trade are yours to reason about: 1. **Cheap feed, freshness matters.** A short delay — one or two seconds — means a console that flickers offline for a moment is current again almost immediately. This is the usual choice for a warning surface where a stale threshold crossing is the whole risk. 2. **Expensive feed.** If re-opening means re-authorising, re-reading a snapshot and re-subscribing to a dozen gauges, a one-second delay turns a brief network wobble into repeated expensive work. Lengthen it. 3. **You are shedding load.** Raising the advertised delay before you start closing responses spaces out the return traffic. Note the limit of the mechanism: it is a single number, identical for every client that reads it, so it cannot by itself stop a fleet from coming back in lockstep. Spreading reconnects out per client is a technique that lives above this field, not inside it. ## The three things candidates get wrong The unit is the first: milliseconds, and a value written as if it were seconds is a thousandfold error in the wrong direction. The direction is the second: this is a response field, and a client never sends it. The third is a cross-protocol collision — in an RPC framework a "retry" is a policy for re-issuing a failed call, possibly several times, possibly with backoff. Here it is not a policy and not a count. It is one delay, before one re-open of one stream, of a client that was going to re-open anyway.