This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix ClientWebSocket close handshake when using proxy (#36928)
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
- Loading branch information
Showing
5 changed files
with
47 additions
and
14 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters