Comment by 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.