-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ClientWebSocket aborts on closes when going thru a proxy #25440
Comments
cc: @dotnet/ncl |
Created new tests for verifying ClientWebSocket connections end-to-end thru a proxy. Opened new issues #28024 and #28027 which cause the new tests to fail. Fixes #26957
It seems that the behavior differs depending on which proxy is used. Using the test 'HappySockets' proxy server, we get a RST back after the close frame (which causes this test failure). Using Fiddler, we get a FIN. However, the test passes using .NET Framework and 'HappySockets' proxy server. Need to investigate further to determine whether or not this is a test bug (proxy server shouldn't be sending back RST) or a difference between .NET Core and .NET Framework. |
Created new tests for verifying ClientWebSocket connections end-to-end thru a proxy. Opened new issues #28024 and #28027 which cause the new tests to fail. Fixes #26957
When the client websocket was going through a proxy, it would sometimes transition to the 'Aborted' state and not the 'Closed' state after a successful closing handshake. I first opened this bug a year ago but finally was able to get back to it and root cause the problem. The problem only occured with the managed websocket. The .NET Framework did not have this problem. And some proxies didn't cause a problem with managed websocket (such as Fiddler). The root cause is a misinterpretation of RFC 6455, Section 7.1.1. This describes the behavior of how the websocket's TCP connection should be closed. The most graceful way is to wait for the server to initiate the close of the socket. In cases where it is taking too long to wait for the server to start the TCP close, then the client can start the TCP close of the socket. But no matter how the socket is finally closed, the websocket state should transition to 'Closed' as soon as a valid closing handshake was performed (i.e. close frames both sent and received). And this occurs before any logic for closing the TCP connection. The code in managed websocket has a timer to wait 1 second for the server to start a close. If the timer finishes, then the managed websocket calls an Abort() method to close the socket. This ends up transitioning the websocket to an 'Aborted' state which is incorrect. The state should only be moved to the 'Aborted' state if a closing handshake was not completed. I added a new test to support this change and moved the LoopbackProxyServer code to Common. Fixes #28027
When the client websocket was going through a proxy, it would sometimes transition to the 'Aborted' state and not the 'Closed' state after a successful closing handshake. I first opened this bug a year ago but finally was able to get back to it and root cause the problem. The problem only occured with the managed websocket. The .NET Framework did not have this problem. And some proxies didn't cause a problem with managed websocket (such as Fiddler). The root cause is a misinterpretation of RFC 6455, Section 7.1.1. This describes the behavior of how the websocket's TCP connection should be closed. The most graceful way is to wait for the server to initiate the close of the socket. In cases where it is taking too long to wait for the server to start the TCP close, then the client can start the TCP close of the socket. But no matter how the socket is finally closed, the websocket state should transition to 'Closed' as soon as a valid closing handshake was performed (i.e. close frames both sent and received). And this occurs before any logic for closing the TCP connection. The code in managed websocket has a timer to wait 1 second for the server to start a close. If the timer finishes, then the managed websocket calls an Abort() method to close the socket. This ends up transitioning the websocket to an 'Aborted' state which is incorrect. The state should only be moved to the 'Aborted' state if a closing handshake was not completed. I added a new test to support this change and moved the LoopbackProxyServer code to Common. Fixes #28027
@davidsh, there's still a test disabled against this issue: runtime/src/libraries/System.Net.WebSockets.Client/tests/ClientWebSocketOptionsTests.cs Lines 65 to 68 in ccf6aed
|
Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process. This process is part of our issue cleanup automation. |
While working on #24965, I noticed that the following test will fail. There seems to be a problem with the close frame exchange and final TCP socket close when going thru a proxy.
Repro test (not yet in repo):
Fails with error:
The text was updated successfully, but these errors were encountered: