{"push_id":2362089552,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"eb80d133d066e72626643dddb3171bf9bb6a7c42","before":"bfc490d6a4cef40cd4cabf2cafa00874d288eee8","commits":[{"sha":"eb80d133d066e72626643dddb3171bf9bb6a7c42","author":{"name":"Stephen Toub","email":"b60ab4ec0ae5032e51dd285ac67105c722f075d3@microsoft.com"},"message":"Add MaxResponseDrainSize, and fix a few draining bugs (#27476)\n\n* Add MaxResponseDrainSize, and fix a few draining bugs\r\n\r\nI've added MaxResponseDrainSize to make the setting configurable rather than a const; I left it internal until the API is approved.\r\n\r\nIn adding tests for it, I found a few existing bugs in draining that I fixed:\r\n- HttpConnectionResponseContent nulls out its Stream when the Stream is consumed.  Then when the response content is disposed, the Stream is null, so it's not disposed, so it's not drained.\r\n- HttpContentReadStream's Dispose wasn't checking whether it was already called, and would kick off a new draining operation if the connection was still associated.  So if the stream was disposed multiple times, which happens if the response content and stream are both disposed (since the content disposes of the stream), we end up corrupting the response due to multiple threads concurrently accessing and draining it.\r\n\r\n* Address PR feedback","distinct":true,"url":"https://api.github.com/repos/dotnet/corefx/commits/eb80d133d066e72626643dddb3171bf9bb6a7c42"}]}
{"actor":{"display_login":"stephentoub"}}