TL;DR
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
Go 1.27 changes how net/http handles HTTP/1 response bodies when callers close them without reading to the end. In the Go blog’s example, 100 status-code requests took about 150 milliseconds on Go 1.27 versus about 710 milliseconds on Go 1.26, though the result is specific to that test and machine.
Go 1.27 changes the net/http client’s HTTP/1 connection reuse behavior for responses whose bodies callers close without fully reading. In a Go team example making 100 requests to index.golang.org, the same status-code-only program took about 150 milliseconds on Go 1.27, compared with about 710 milliseconds on Go 1.26, because the client can avoid discarding connections in this situation.
The example uses HTTP/1, with HTTP/2 disabled through GODEBUG=http2client=0. Its function sends a GET request, defers closing the response body, and returns only the status code. It does not consume the body. The Go report says that through Go 1.26, closing this unread body meant net/http abandoned the connection rather than reusing it for the next request. Repeated calls could then pay the cost of setting up new connections.
That setup can involve TCP and TLS handshakes before an HTTP request is sent. The report explains that a new TCP connection typically takes one round trip, while a TLS 1.2 handshake takes two more; TLS 1.3 can complete its handshake in one round trip in the example’s conditions. Connection setup time varies with protocol and network latency, so the example’s measured improvement is not a general benchmark for every application.
With the Go 1.27 change, closing an HTTP/1 response body without reading it no longer necessarily prevents the connection from being reused. The report’s measurement is a single example on the author’s machine, and does not specify a range of workloads or machines. Applications that need response data still need to read it; the change concerns the connection’s reuse, not whether the body’s contents are available to the caller.
Fewer Handshakes for HTTP/1 Clients
The change may reduce latency and connection overhead in Go programs that make repeated HTTP/1 requests but use only response status codes or otherwise close bodies early. Avoiding a new connection can save network round trips and TLS processing. The effect is most relevant when connection setup is a substantial share of request time, including communication over higher-latency networks.
It also addresses a behavior that can be easy to miss in ordinary client code: a request can succeed and return the status while an unread body quietly prevents the next request from sharing the connection. Developers may see slower repeated requests without an obvious application error. Go’s reported adjustment reduces the need to read and discard a body solely to preserve reuse in this case, although exact behavior and performance depend on the endpoint, protocol, and workload.
The change is specific to HTTP/1’s sequential response stream. HTTP/2 multiplexes requests over a connection, so an unread body on one stream does not block other requests from using that connection in the same way. The performance figure therefore should not be read as a broad claim about all Go HTTP clients or protocols.
HTTP/1.1 and HTTP/2 network testing tools
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Why Unread Bodies Matter
HTTP/1 responses on one connection arrive sequentially. The client must identify where one response ends before it can parse the next. When a caller reads only the status and headers, the body may remain unread; under the behavior described for Go versions through 1.26, closing it led the client to abandon that connection because the next response could not safely be located in the stream.
Developers have often worked around this by draining the response body before closing it. That can permit reuse when the body is manageable, but it means reading bytes the application does not need. The issue can also occur when code reads almost all of a body: the report gives JSON decoding as an example, where a decoder may stop at the closing brace and leave a trailing newline unread.
HTTP/1.1 connections are persistent by default, while HTTP/1.0 commonly relies on keep-alive headers to request reuse. HTTP/2 works differently, allowing multiple streams over one TCP connection. The Go report’s benchmark deliberately disables HTTP/2, isolating the HTTP/1 behavior rather than measuring the client’s general performance across protocols.
“On Go 1.26 on my machine, 100 calls take about 710 milliseconds; on Go 1.27, the same program takes about 150 milliseconds.”
— Go team, in the go.dev report
As an affiliate, we earn on qualifying purchases.
Limits of the Reported Benchmark
The supplied report does not specify the full test environment, including machine details, network conditions, number of benchmark repetitions, or variation between runs. The 710-millisecond and 150-millisecond figures are therefore best understood as the result of the stated example, not a promised speedup for other programs.
The material also does not detail the implementation mechanics or define every condition under which Go 1.27 can retain an HTTP/1 connection after a body is closed early. The result may vary with response framing, server behavior, request pattern, and whether the application uses HTTP/1 or HTTP/2. No broader set of benchmarks is provided in the source material.
HTTP connection reuse monitoring tools
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Check Results in Your Workload
Go users can compare repeated HTTP/1 requests on Go 1.27 with their existing version, taking care to control for network conditions and response sizes. The Go report’s example uses GODEBUG=http2client=0 to isolate HTTP/1; results from applications negotiating HTTP/2 may differ.
For applications that depend on response contents, callers should continue to read and handle those contents as required. Teams reviewing latency should also check their actual protocol and request patterns rather than assume the example’s timing applies directly. The source material does not give a release date or identify further benchmarks, so broader performance data and release details remain to be confirmed.
Go programming language HTTP client libraries
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Key Questions
What changed in Go 1.27?
The Go report says net/http improves HTTP/1 connection reuse when a caller closes a response body without reading it all. Previously, that could cause the client to abandon the connection.
How much faster is the reported example?
The Go team measured 100 requests to index.golang.org at about 150 milliseconds on Go 1.27 versus about 710 milliseconds on Go 1.26, with HTTP/2 disabled. The figure is specific to that test and machine.
Does this change apply to HTTP/2?
The reported improvement concerns HTTP/1. HTTP/2 multiplexes streams on one connection, so an unread response body does not block other requests from sharing the connection in the same way.
Should applications stop reading response bodies?
No. Applications still need to read response data they require. The change addresses whether a closed, unread body necessarily prevents HTTP/1 connection reuse; it does not replace normal response handling.
Is the speedup guaranteed for Go programs?
No. The reported timing comes from one example and does not establish a general speedup. Results depend on network conditions, protocol, server responses, and the application’s request pattern.
Source: hn
Halloween Picks
halloween
As an affiliate, we earn on qualifying purchases.
