[mappu]

Go's http.Client will keepalive a TCP/TLS connection to save you handshake latency on second requests. But it can only do this if you completely finish reading the last request.

Now in 1.27:

> http.Response.Body drains itself on Close. For HTTP/1, closing the body now reads and discards any unread content (up to a conservative limit) so the connection can be reused. For most programs this is a transparent win [...]

Great, so i no longer have to io.Copy(io.Discard, resp.Body) in the err case, one less thing to worry about; but

> if you were leaning on an early Close to abort a large download, set Transport.DisableKeepAlives to opt out.

That's a subtle behaviour change. Any previous Go program which used Close in this way - say for an infinite event stream - now hangs, soaking up bandwidth.

In the past, the Go team have searched the entire Github corpus for misuse before making changes like this. I don't have a reference but I assume an appropriate level of consideration went into this decision.

EDIT: ""up to a conservative limit"" so this is not so bad after all.

[spockz]

Is “a conservative limit” a high limit or a low limit? If it is high such that many responses will still be drained it would keep reading those infinite streams for a long time. If it is low it might still not drain all normal sized messages.

Anyway, this is why it pays off to read release notes closely and have a decent test suite.

[mxey]

The drain is asynchronous, so it won’t block. The limit is 256 KB and 50 ms.