Fix ProxyExplicitlyProvided_DefaultCredentials_Ignored test #28770
Conversation
I couldn't get it to fail locally, but I believe the issue was that sporadically WinHttpHandler would not reuse the original connection, in which case it would either not close the first and the test would hang because nothing was accepting the second connection, or it would close the first and fail because the server was expecting a second request on the connection. This fixes it by using Connection: close on the first response so that the client won't reuse the same connection.
Well-behaved servers will always send an HTTP response header that matches their connection behavior. So, if a server does close the connection after the request (despite the client wanting to do 'keep-alive'), the server will send 'Connection: close'. This helps the client figure out immediately that the connection is gone. Much of our test code is written using the loopback server and doesn't follow these principles. It will close the connection after one request but doesn't send any 'Connection: close' response headers. In some ways, this is a good test to see if how resilient our client HTTP stack is. But as we've seen, there are race conditions and we end up having to do fixes like this. Perhaps we should consider making our test code follow well-behaved patterns for servers and make sure the loopback server use is well-behaved. |
|
cc: @geoffkizer |
This case is a bit different. The server wasn't closing the connection, and was expecting the client to reuse it; the hang or failure would occur when the client didn't reuse it. Regardless, yes, we need to be more cognizant of this in tests. |
|
And according to the RFC, it is a MUST that the server send 'Connection: close' if it is going to close the connection.
|
…orefx#28770) I couldn't get it to fail locally, but I believe the issue was that sporadically WinHttpHandler would not reuse the original connection, in which case it would either not close the first and the test would hang because nothing was accepting the second connection, or it would close the first and fail because the server was expecting a second request on the connection. This fixes it by using Connection: close on the first response so that the client won't reuse the same connection. Commit migrated from dotnet/corefx@586cffc
4 participants
I couldn't get it to fail locally, but I believe the issue was that sporadically WinHttpHandler would not reuse the original connection, in which case it would either not close the first and the test would hang (and then the client would timeout) because nothing was accepting the second connection, or it would close the first and fail because the server was expecting a second request on the connection. This fixes it by using Connection: close on the first response so that the client won't reuse the same connection.
Fixes https://github.com/dotnet/corefx/issues/28537
Fixes https://github.com/dotnet/corefx/issues/25983
cc: @wfurt, @rmkerr