Comment 2:

This is on purpose.
The way it was before was surprising and made things impossible. The way it is now means
it does what you say, but you can still wrap the ReadCloser with one that reads-to-EOF
on Close, if so desired.

Status changed to WorkingAsIntended.

Comment 3:

Thanks for the clarification. The change in behaviour was surprising and caused
significant performance degradation in some apps I maintain.
Can you tell me when the change in behaviour occurred, and ensure the documentation is
clarified? It relevant part I find currently reads: "The client must close the response
body when finished with it" which is insufficient detail.

Comment 4:

I'm not sure I want to clarify (read: guarantee) the behavior either way. I reserve the
right to change the heuristic in the future. (e.g. maybe read-to-EOF if I know EOF is
coming "soon", for some definition of "soon", or as a function of whether SPDY is
enabled, or whether TCP Fast Open is enabled for that host, etc, etc)
But probably I just won't be changing it now.

Comment 5:

Could you perhaps document that keep alive isn't guaranteed unless the response body is
discarded?

Comment 6:

I just discovered this issue and was surprised that I've been reading JSON from HTTP
responses incorrectly this whole time. I was even more surprised that nowhere in the
docs does it say you need to read the entire Body if you want the conn to be reused,
though it does say that you need to call Close().
Here's an example that shows how it's so easy to do this wrong, not knowing that some
extra whitespace after the JSON object could cause conns not to be reused:
http://play.golang.org/p/QMc9Dt0btS
If you don't think you should change the behavior, I really think it should at least be
documented.

Comment 7:

Okay, I'll document something for Go 1.5.
Note that in HTTP/2 this whole issue is moot.

Labels changed: added release-go1.5, repo-main, documentation, removed priority-triage.

Owner changed to @bradfitz.

Status changed to Accepted.

Sent https://go-review.googlesource.com/#/c/1531/