Bodies and Connection Reuse

### The body is a live stream, not a buffer `http.Client.Do` — and the wrappers `http.Get`, `http.Post`, `http.PostForm` that call it — return as soon as the response *status line and headers* have been read. The payload has usually not been transferred yet. `resp.Body` is an `io.ReadCloser` layered on top of the still-open TCP (or TLS) connection to the server: reading it pulls bytes off the wire, and closing it tells the `net/http` Transport that you are finished with that stream. That is why closing is the caller's responsibility and not the library's. `net/http` cannot know when you have stopped caring about a response, so until `Close` is called the Transport must assume the stream is still in use. Nothing in the runtime rescues you: there is no finalizer that closes response bodies, so "the GC will clean it up" is simply wrong. ### What an unclosed body costs * **A socket and its file descriptor.** Every live connection holds one. A daemon that leaks one per request climbs steadily until the process hits its descriptor ceiling, at which point *everything* that needs a new descriptor starts failing — not just HTTP. * **A connection that can never be reused.** The Transport only returns a keep-alive connection to its idle pool after the body has been read to EOF *and* closed. An unclosed body pins that connection out of circulation, so the next request pays for a new DNS lookup, TCP handshake and TLS handshake. * **Reader goroutines and buffers.** Each in-flight HTTP/1 connection has bookkeeping behind it; leak enough of them and the leak shows up as memory growth as well as descriptor growth. ### Where the defer goes The canonical shape is three lines and the order of them matters: ```go resp, err := http.Get(url) if err != nil { return err } defer resp.Body.Close() ``` When `Do` returns a non-nil error, `resp` is nil. Putting the defer first therefore panics with a nil pointer dereference on the way out of the function — a very common beginner bug, and one that turns a recoverable network error into a crash. The mirror-image mistake is skipping the close on a non-2xx response. A 404 or a 500 is a perfectly successful HTTP exchange as far as the client is concerned: `err` is nil, the body is non-nil, and the connection is real. Check the status code *after* arranging the close, never instead of it. `http.Response`'s documentation guarantees that `Body` is non-nil whenever the error is nil, even for a 204 No Content or a response to a HEAD request. In those cases the first `Read` simply returns `io.EOF`. So there is never a case where you must nil-check the body before closing it. ### Deferring inside a loop ```go for _, url := range urls { resp, err := http.Get(url) // wrong: one open body per iteration if err != nil { return err } defer resp.Body.Close() // ... } ``` `defer` runs at *function* return, not at the end of the loop iteration, so this holds every body open until the whole loop finishes. With a thousand URLs that is a thousand open sockets. The fix is to move the request into its own function (or a closure invoked per iteration) so the defer fires each time round, or to close explicitly at the end of the iteration on every path. ### The request body is not your problem A frequent confusion: you do **not** close `req.Body`. When you hand a body to `http.NewRequest` or `http.NewRequestWithContext`, the `http.Client` takes ownership and closes it, on success and on failure alike. Closing it yourself can turn into a use-after-close on a retry. Only the *response* body is yours. ### Closing is necessary but not sufficient Closing releases the descriptor, but it does not by itself guarantee the connection is *reused*. For a keep-alive connection to go back into the Transport's idle pool the body normally has to be read to EOF first; closing an HTTP/1 body with a large unread remainder still costs you the connection. That is a separate discipline — draining — layered on top of the rule here. The rule here is unconditional: if `err` is nil, the body gets closed. ### What the error from Close means `Close` returns an error, and on a response body it is almost always ignored — there is nothing meaningful to do about a failure to tear down a read side, and linters that demand it are usually satisfied with `defer func() { _ = resp.Body.Close() }()`. That is unlike a *file you wrote to*, where the close error can be the first sign that your data never landed.