In net/http, why is it invalid to read r.Body after ServeHTTP has returned?

## The lifetime rule Go's HTTP server lends you three things for exactly as long as your handler is on the stack: the `http.ResponseWriter`, the `*http.Request`, and the request body hanging off it. `net/http` documents this plainly — the server closes the request body so the handler does not have to, and a `ResponseWriter` may not be used after `ServeHTTP` returns. Everything else follows from that. ## What the server actually does when you return When `ServeHTTP` returns, the server finishes the response, closes `r.Body`, and — if the connection is keep-alive and the protocol allows it — reuses that same connection for the next request. Reuse is the dangerous part. The body of an HTTP/1.1 request is not an independent stream; it is a view over the connection's reader, bounded by `Content-Length` or by chunked framing. Once the server moves on, that reader is positioned at the *next* request's bytes. So a late read is not merely useless: - it typically returns an error such as `http.ErrBodyReadAfterClose`, or an immediate EOF; - and where it does not, it is touching state the server is concurrently using, which the race detector will report if you exercise the path under `-race`. ## Why the mistake is easy to make The shape that produces it looks reasonable: ```go func handler(w http.ResponseWriter, r *http.Request) { w.WriteHeader(http.StatusAccepted) go func() { body, _ := io.ReadAll(r.Body) // wrong: handler has returned archive(body) }() } ``` The author reasoned about the *pointer* — `r` is still reachable, so surely it is still usable. But reachability is not validity: the request value survives, and the resource behind it does not. The goroutine usually records an empty payload, which is why this bug is often discovered weeks later as a table full of zero-length rows rather than as a crash. ## The fix Do the reading while the handler is still running, and pass a value the goroutine owns: ```go body, err := io.ReadAll(r.Body) if err != nil { http.Error(w, "bad body", http.StatusBadRequest) return } go archive(body) ``` The same applies to anything else derived from the connection: if a goroutine needs a header value, a path parameter or the remote address, copy the string out first. Copying a `[]byte` is enough because the slice you got from `io.ReadAll` was freshly allocated; a slice you carved out of a server-owned buffer would need a real copy. A decoded struct is usually the better hand-off anyway: it is smaller, it fails inside the handler where you can still return `400`, and it makes the background work independent of the wire format. ## Adjacent good practice Even inside the handler, reading an unbounded body is a hazard — a client can stream gigabytes into `io.ReadAll`. Wrapping the body with `http.MaxBytesReader` caps it and makes the server reject the excess. That is about resource safety rather than lifetime, but the two decisions land in the same three lines of code. And note the boundary with the other half of this topic: getting the *payload* to a background goroutine safely, as above, does not by itself make that goroutine correct. It still needs a context that is not the request's, a bound on how long it may run, and a plan for what happens if the process exits first. ## What a good answer includes Name the ownership: the server closes the body and reuses the connection. Name the symptom: empty or errored reads rather than a loud failure. Name the fix: copy or decode inside the handler. And extend the rule to the `ResponseWriter`, because the same person who reads a stale body usually also writes to a stale writer.