I found this by investigating other test issues...
The only place we call RemoveStream is when the user calls Dispose on the response Stream. That means that if they never call Dispose, we will be waiting potentially forever for GC to kick in and finalize the stream, and this will delay closing the connection.
We should instead remove the stream as soon as it is complete, i.e. request and response both fully sent/received or aborted. This is how HTTP/1.1 and HTTP2 work (I think).
Note this only matters when using HttpCompletionOption.ResponseHeadersRead.
You can reproduce this by cancelling the read on an incomplete response and then trying to shut down the server without disposing the response. See for example the GetAsync_CancelDuringResponseBodyReceived_Unbuffered_TaskCanceledQuickly test.
I found this by investigating other test issues...
The only place we call RemoveStream is when the user calls Dispose on the response Stream. That means that if they never call Dispose, we will be waiting potentially forever for GC to kick in and finalize the stream, and this will delay closing the connection.
We should instead remove the stream as soon as it is complete, i.e. request and response both fully sent/received or aborted. This is how HTTP/1.1 and HTTP2 work (I think).
Note this only matters when using
HttpCompletionOption.ResponseHeadersRead.You can reproduce this by cancelling the read on an incomplete response and then trying to shut down the server without disposing the response. See for example the GetAsync_CancelDuringResponseBodyReceived_Unbuffered_TaskCanceledQuickly test.