I was mistaken about us removing the stream from ClientConn.streams upon receiving a response with a status >=300. We only remove the stream later, usually when Request.Body is closed.
When Request.Body is closed, we send a RST_STREAM if the server hasn't closed its side of the stream. If the server has closed its side of the stream, we forget the stream and send nothing.
If Request.Body is closed when the server has closed its side of the stream and we have not finished writing the request body, we will abandon the stream in a half-closed state. This is true whether we received a >= 300 status or not, but it is more likely to occur in this case because a 300 response halts the body write.
So a client-initiated stream is left unclosed if:
There is a request body.
The body is not fully written when Response.Body is closed.
The server half-closes the stream before Response.Body is closed.
I haven't found a way to demonstrate this condition with the x/net/http2 server, because our server implementation sends a RST_STREAM after sending any frame which half-closes a stream. (See *serverConn.wroteFrame.)
On receiving a 3xx, 4xx, 5xx, etc. response while writing a request body, the HTTP/2 RoundTrip cancels the body write and returns:
In this case, the client does nothing to terminate its side of the stream--it doesn't send END_STREAM or RST_STREAM. The stream will remain open or in a half-closed state until the server resets it.
In addition, we remove the stream from
ClientConn.streamsin this case, which means we no longer count it against the stream concurrency limit.
We should either send a RST_STREAM when we've given up writing, or write the request body even on a 3xx etc response. (The server can still reset the stream if it doesn't care about the body.)
The text was updated successfully, but these errors were encountered: