Go HTTP Connection Reuse: What Changes in Go 1.27

Reuse avoids repeated setup

Most HTTP clients will try to keep connections around so they can reuse them for later requests. People call this connection reuse or keep-alive. When it works:

• The client can avoid creating a new TCP connection.
• For HTTPS, it can avoid repeating the TLS handshake each time.

The details depend on the HTTP version:

• HTTP/1.0 connections aren't persistent by default, though both sides often use Connection: keep-alive to request reuse.
• HTTP/1.1 connections are persistent by default unless one side indicates it will close (for example, Connection: close).
• HTTP/2 multiplexes multiple request/response streams on one connection. In HTTP/2, an unread response body on one stream doesn't block other streams the same way.

Reuse helps most for clients doing sequential requests to the same host. But "persistent" doesn't automatically mean "reusable." The client also has to know where one response ends and the next begins.

A simple benchmark can reveal the issue

Here's a function that only needs the status code:

func getStatus(url string) (int, error) {
resp, err := http.Get(url)
if err != nil {
return 0, err
}
defer resp.Body.Close()
return resp.StatusCode, nil
}

The body is closed, so you'd expect the transport to be able to move on. The catch is that closing isn't always the same as consuming the whole response. In older Go versions, if the client didn't read the remainder of an HTTP/1 response, the transport may not reuse that connection for the next request.

That's why this can feel so "mysterious" in practice: the code looks careful, there's no obvious leak, and the wrongness doesn't show up as incorrect status codes. The performance hit is just repeated connection setup hidden behind an otherwise ordinary http.Get.

Closing is not always consuming

Imagine a server returns a JSON body like:

{"success":true,"message":"update processed"}

Your code only needs the status code, so you don't read the body. You close it. On older Go versions, the transport may still treat that response as "unread" and refuse to reuse the connection, because the stream position is no longer at a known response boundary. The transport then discards the connection and has to establish a new one.

This can happen even when the remaining data is small. For example, encoding/json.Decoder can stop after decoding the JSON value. If the server sends a newline after the closing brace, that newline might never be read. The connection still isn't positioned at the end of the HTTP/1 response, even though it feels like it should be "one byte away."

The key point: HTTP/1 reuse depends on getting to the end of the current response before the connection can carry the next one.

Why HTTP/2 behaves differently

HTTP/2 doesn't use the same "one shared byte stream for everything" model. It multiplexes frames from multiple streams over one connection. If one response body is unread, it only occupies its own stream, so it doesn't automatically block reuse for other requests on the same connection.

That's not permission to ignore the body. You still need to close responses and release resources. It just means the specific HTTP/1 failure mode - unread data blocking the next response boundary on a shared stream - doesn't apply in the same way.

This matters when you're debugging. A workaround meant for HTTP/1 might add extra work for HTTP/2 without any benefit. The best move is to confirm which protocol is in play and where the time is really going.

Common patterns that trigger it

This shows up most easily when the code doesn't actually need the response content:

• A health check that only reads the status code.
• A service that calls an API, but ignores the response message.
• Code that reads one value from a response and then exits early.
• A JSON decoder that stops at the end of a value while trailing whitespace/newlines remain.

None of these patterns are "wrong" by themselves. Reading and discarding a body you don't need is still work, and it can be wasteful if the response is large. The issue is that older HTTP/1 behavior could make the alternative - closing without reading - cause connection churn on the next request.

What manual draining fixes - and what it can cost

Before Go 1.27, a common workaround was to drain the remaining bytes into io.Discard before closing:

func drainAndCloseBody(body io.ReadCloser) {
io.Copy(io.Discard, body)
body.Close()
}

For a small response that arrives quickly, this can help the transport reach the response boundary and reuse the connection. But draining without limits is a bad habit: if the response is large, you may end up downloading a ton of data your application will never use, taking longer and consuming more bandwidth than opening a new connection would have.

A safer workaround caps what you read and often also caps how long you'll wait. But that adds complexity: you need to decide on byte/time limits, and you have to make sure the drain interacts correctly with closing and goroutine behavior. Even "just" making a helper is non-trivial when you want it to be correct and reusable across a codebase.

That's why sprinkling an unbounded io.Copy into request paths is rarely a complete production strategy.

Keep application code straightforward

With Go 1.27, the recommended approach is still simple: close the response body when you're done.

func getStatus(url string) (int, error) {
resp, err := http.Get(url)
if err != nil {
return 0, err
}
defer resp.Body.Close()
return resp.StatusCode, nil
}

You don't need to manually drain every response just to encourage HTTP/1 reuse. Let the transport do the bounded cleanup. Your application stays focused on the data it actually needs, and net/http handles the transport mechanics it already knows how to do well.

And yes, this doesn't remove the need to close bodies. You should still close responses even on error paths where you return a Response alongside an error. Go 1.27 just makes connection reuse more resilient when your code hasn't consumed the body fully.

What to do on older Go versions

If you're stuck on an older Go release and sequential HTTP/1 requests are slow, start by measuring. Don't add a generic "drain everything" helper everywhere and hope for the best.

A practical investigation looks like this:

1. Confirm the protocol. HTTP/1 and HTTP/2 have different reuse behavior. If you can, use GODEBUG=http2client=0 to help isolate HTTP/1 behavior.
2. Check whether requests are sequential and target the same host. Reuse only helps when a later request can share a connection that's still available.
3. Inspect how response bodies are handled. Look for code that closes without reading, or decoders that stop early.
4. Benchmark with realistic responses and latency. A local test with a tiny body might hide the costs that show up across regions or with TLS.
5. If you add draining, bound it. Set a maximum byte count and consider the time cost. An unlimited drain can turn a performance optimization into a bandwidth/availability problem.
6. Upgrade and retest where possible. The transport is part of the client implementation. In Go 1.27, the "right" behavior may already be built in.

For client and transport API details, see the net/http package documentation. The original explanation is also available in the Go blog post on HTTP connection reuse.

Avoid applying HTTP/1 workarounds to every protocol

Don't drain blindly everywhere. The goal is to prevent avoidable connection churn without doing more work than the request is worth.

For HTTP/2, consuming an unused body to help another request generally isn't necessary, because streams are multiplexed. For HTTP/1, reading the remainder can help reuse - but it can also cost time and bandwidth. Go 1.27 addresses the "common case" by doing bounded draining inside the transport.

Ultimately, the right behavior depends on protocol, body size, server behavior, and workload. In real codebases, the safest default is: keep application code simple, use the standard transport, and measure before adding protocol-specific machinery.