Imagine you're at a buffet with a strict rule: you can't get a new plate until you've scraped the old one clean. Even if you only wanted the salad, you have to deal with every grain of rice before you're allowed back in line. That's how Go's HTTP/1 client has worked since forever — if you didn't read every last byte of a response body, the TCP connection was thrown away and a new one had to be built from scratch, complete with handshakes. The blog post from the Go team documents what amounts to a 15-year ergonomic debt payment. The core problem: HTTP/1 sends responses back-to-back on the same TCP stream. The client can only find where the next response starts after fully consuming the current body. If your code only reads the status code and calls resp.Body.Close(), the runtime sees unread bytes and abandons the connection. Every subsequent request pays the full TCP + TLS setup cost — typically 2-3 round trips, easily 300+ ms cross-region. The numbers are stark. On Go 1.26, 100 sequential GETs to index.golang.org over HTTP/1 take ~710 ms. On Go 1.27, the same code takes ~150 ms — a 4.7x speedup with zero code changes. The entire delta is connection reuse. The fix is elegant: net/http.Transport now asynchronously drains unread HTTP/1 response bodies for up to 50 ms or 256 KB, whichever comes first. It races the drain against the next outbound request, so the caller never blocks. If the drain finishes in time, the connection is reused; if not, a new connection is created and the old one enters the idle pool. The post walks through the manual workaround that Go developers have cargo-culted for years — io.Copy to io.Discard before closing — and shows how the 'correct' version requires byte caps, time caps, and goroutine management to avoid blocking and leaks. This is exactly the kind of complexity that belongs in the standard library, not in every HTTP caller. The auto-drain also skips bodies when Connection: close is set, since draining would be wasted work. What makes this interesting beyond Go is the failure mode it documents. The encoding/json.Decoder case is particularly nasty: a JSON object followed by a single trailing newline leaves one byte unread, which is enough to prevent connection reuse. The connection is abandoned despite being one byte from reusable. This class of bug — invisible performance degradation from a correct-looking code path — is among the hardest to diagnose. The change is HTTP/1-only. HTTP/2 multiplexes frames over a single connection, so unread bodies on one stream don't block others. This makes the fix a targeted patch for a protocol-specific sharp edge rather than a fundamental architectural change. The Go team notes the behavior may evolve in future versions as additional optimizations become apparent. The broader lesson: standard library defaults are load-bearing infrastructure decisions. For over a decade, the 'obvious' way to use net/http — read the status, close the body — silently degraded performance. The fix isn't novel computer science; it's the Go team finally absorbing complexity that thousands of developers were handling (or mishandling) independently.
