An HTTP client sends a request, the TCP connection drops, and no response ever arrives. Under HTTP's own rules, when may the client automatically retry that request, and what must it never retry automatically?

## The rule RFC 9110 §9.2.2 states that a client **SHOULD NOT** automatically retry a request that is not idempotent, and that automatic retry is appropriate when the method is idempotent and the client received no response. Everything else in this area follows from that sentence plus one hard fact about networks. ## The fact that makes it hard: the ambiguity of silence When a connection dies with no response, exactly one of these happened, and the client cannot tell which: 1. The request never reached the server. 2. The request reached the server, was fully processed, and the **response** was lost. 3. The request was partially processed and the server crashed midway. Case 2 is the killer. If the method is POST `/payments`, a retry in case 2 charges the card twice. If the method is `PUT /users/42` with a full representation, a retry in case 2 writes the same bytes again and nothing is harmed. That asymmetry *is* the retry rule — idempotency is precisely the property that makes the ambiguity irrelevant. So the guarantee HTTP gives an automatic retrier is **at-least-once with convergent effect** for idempotent methods, and nothing at all for non-idempotent ones. ## What may be retried automatically - **Idempotent methods with no response received.** GET, HEAD, OPTIONS, TRACE, PUT, DELETE. This is what connection pools do when they hand out a stale keep-alive connection that the server has already closed: the request goes out, the socket resets, and the client silently re-dispatches on a fresh connection. Almost every HTTP client library implements exactly this and nothing more. - **Any method, when the server has explicitly signalled it did not process the request.** These signals are what let you retry a POST safely: - **HTTP/2 `REFUSED_STREAM`** — the RST_STREAM error code defined to mean "this stream was not processed"; the request may be retried on another connection. - **GOAWAY with a last-stream-id below your stream id** — the server is telling you precisely which streams it did not handle. - **421 Misdirected Request** — this connection cannot serve the target authority; the request wasn't processed here, retry elsewhere. - **425 Too Early** — the server refuses to process TLS 1.3 early data (0-RTT), which could be replayed; retry after the handshake completes. - **503 Service Unavailable / 429 Too Many Requests**, typically with `Retry-After` — the server is declining, not processing. Retry after the indicated delay, with backoff and jitter. - **408 Request Timeout** — the server gave up waiting for the request; nothing was processed, so the request may be repeated. ## What must not be retried automatically **POST and PATCH after an ambiguous failure.** No transport-level component may do this: not the client library, not the connection pool, not the reverse proxy, not the service mesh sidecar. If middleware in your stack retries POSTs on timeout by default, that is a production incident waiting for its trigger, and it is one of the first things worth auditing in a payments path. Also worth stating: a **timeout is not a failure signal**. When a client times out, the server may still be working and may complete successfully seconds later. Retrying on client-side timeout is strictly more dangerous than retrying on a connection reset, because the request definitely reached the server. ## The nuance interviewers push on **"But we retry POSTs all the time."** Yes — with an application-level contract that makes the duplicate detectable, so the retry is a deliberate design decision rather than a transport default. HTTP itself gives you no such mechanism; you are layering one on top, and both sides must agree on it. **Idempotent does not mean harmless to retry infinitely.** A retry storm from a fleet of clients hammering an already-degraded server is a self-inflicted outage, whatever the method. Exponential backoff with jitter, a bounded retry count, honouring `Retry-After`, and a circuit breaker are all still required. Idempotency licenses the retry; it does not size it. **Non-idempotent requests can be made retry-safe by narrowing the ambiguity.** If the client can cheaply query whether the effect happened — "does an order with my client reference exist?" — it can resolve case 2 by reading rather than guessing. That read-then-decide pattern is often simpler than it looks and needs no new headers. **Where the bytes stopped matters less than people think.** Some libraries retry only if no request bytes were written. That is a sound heuristic but not a guarantee: the server may have received and processed everything and died before responding. Only idempotency, or an explicit not-processed signal, makes retry genuinely safe. ## Summary Automatic retry is licensed by idempotency or by an explicit "I did not process this" signal from the server. Absent both, a retry is a guess about what happened on the other side, and for POST that guess costs money.