Description
Closing a response body can block indefinitely under at least two circumstances:
Closing a body with unread data returns flow-control tokens for the unread data. If the underlying net.Conn for the request is write-blocked, the attempt to return the tokens can block either while acquiring the stream write mutex, or while writing the window update to the connection.
Closing a response body waits for the request stream to be cleaned up, or the request context to expire, whichever comes first. This ensures that there is no lingering per-request state remaining after a nil response from resp.Body.Close. (We don't guarantee this property in the package docs, but we do have tests asserting this property. For example, we assume that a request no longer counts against the concurrency limit after a nil response from Close.) If the request writer is blocked reading the request body, we currently have no way to interrupt it and resp.Body.Close will block until the request context is canceled (if ever).
My first thought was that closing the response body could close the request body, interrupting the request writer, but this will require caution: The RoundTripper contract permits RoundTrip to access fields of the request up to the point where the request body is closed. If we change the place we close the request body, we need to be very cautious that we don't access any part of the request after that point.
Test for this second case:
func TestTransportCloseResponseBodyWhileRequestBodyHangs(t *testing.T) {
st := newServerTester(t, func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(200)
io.Copy(io.Discard, r.Body)
}, optOnlyServer)
defer st.Close()
tr := &Transport{TLSClientConfig: tlsConfigInsecure}
defer tr.CloseIdleConnections()
pr, pw := net.Pipe()
req, err := http.NewRequest("GET", st.ts.URL, pr)
if err != nil {
t.Fatal(err)
}
res, err := tr.RoundTrip(req)
if err != nil {
t.Fatal(err)
}
res.Body.Close()
pw.Close()
}