With go version go1.4.1 linux/amd64, there's a logical race in (*net/http.Transport).CancelRequest between the readLoop goroutine at https://github.com/golang/go/blob/release-branch.go1.4/src/net/http/transport.go#L935 and the goroutine that calls Close on the response Body at https://github.com/golang/go/blob/release-branch.go1.4/src/net/http/transport.go#L908 .

The closure on line 908 can cause the net.Conn to be handed off to the connection pool before the canceler is cleared on line 935. A call to CancelRequest at this time will then close the connection, even though it's been returned to the pool. The next request to pull that net.Conn out of the pool will fail.

Contexts make this condition easy to trigger: if a monitor goroutine waits on ctx.Done before calling CancelRequest, it's easy to come up with code that would cause the Context to be canceled upon successful completion of the request (e.g. to clean up after context.WithTimeout).