When http.Server.ReadHeaderTimeout and IdleTimeout are left zero but ReadTimeout is set, what bounds those phases?

## The two fallbacks, stated exactly Two of `http.Server`'s four timeout fields do not simply mean *unbounded* when zero. They defer to `ReadTimeout`: - **`ReadHeaderTimeout`** — the time allowed to read request headers. If it is zero, the value of `ReadTimeout` is used. If both are zero, there is no timeout. After the headers are read the connection's read deadline is reset, so the handler can decide what counts as too slow for the body. - **`IdleTimeout`** — the maximum time to wait for the next request when keep-alives are enabled. If it is zero, the value of `ReadTimeout` is used. If it is negative, or zero while `ReadTimeout` is also zero, there is no timeout. `ReadTimeout` and `WriteTimeout` have no such fallback: zero or negative means no timeout, full stop. ## One number, three phases The practical consequence of the first rule is reassuring. A service that sets only `ReadTimeout` is not as exposed as it looks, because the same number is quietly bounding the header read and the idle wait too. Someone who has set `ReadTimeout` on a public endpoint has, without knowing it, bounded a client that connects and never finishes its request line. The practical consequence of the second rule is the trap, and it is the reason this question gets asked. The recommended shape for services that accept large or streaming request bodies is: - a short `ReadHeaderTimeout`, because headers should always arrive promptly, and - `ReadTimeout` left at zero, so a long upload is not killed by a whole-request deadline and the handler polices the body itself. That configuration is right about the read side and silently wrong about the idle side. `IdleTimeout` looks for `ReadTimeout`, finds zero, and ends up unbounded — so every kept-alive connection that finishes a request and then goes quiet stays open forever, holding its goroutine and buffers. A service can be perfectly hardened against slow headers and still accumulate idle connections without limit. The rule to carry away: **the moment you set `ReadTimeout` to zero, `IdleTimeout` becomes mandatory.** ## Negative versus zero Only `IdleTimeout` distinguishes the two usefully. Zero means *inherit*; negative means *no timeout, and I mean it*. That distinction exists so you can express `ReadTimeout: 30 * time.Second, IdleTimeout: -1` — bound each request tightly, keep connections alive indefinitely between them — which the zero value cannot express, since zero would give you 30 seconds. It is a small piece of API design worth recognising: a field with a fallback needs a third state to opt out of the fallback, and Go spends the negative range on it. ## Picking the numbers Sensible reasoning, rather than copied constants: - **Header phase**: measured in seconds and independent of what the endpoint does. Nothing legitimate takes long to send headers. This is the field that protects a connection before any handler runs, so it should be short even on endpoints where every other bound is relaxed. - **Whole request**: sized to the largest legitimate body at the slowest legitimate upload rate, or zero with the handler taking responsibility instead. - **Idle**: sized in relation to whatever sits in front of the service. If a proxy or load balancer keeps connections warm, the server closing first produces a race where the proxy dispatches a request onto a connection the server is retiring; giving the server the longer idle window makes the proxy the one that retires connections, which is the side that can retry cleanly. ## How to check what you actually configured The fallbacks are invisible in the struct literal, which is why they bite. The reliable check is behavioural rather than by reading: open a connection, send nothing, and see whether it is closed; complete one request, then go quiet, and see whether it is closed. Two probes settle what four fields and two fallback rules actually add up to on this server.