You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RFC 6455 is pretty clear that peers are meant to send a close frame on shutdown, which includes when receiving a close from from a peer.
The idea is that nobody tears down the TCP connection until both sides have received close frames from the other side. (Well sort of ... the second sender can initiate a close once the message is issued and pushed on the wire.)
I'm going to set aside SO_LINGER related issues for the moment and just focus on WS_CLOSE handling.
This was pointed out by @alawn-wang in #1722 - but that PR was a bit incomplete as it only did the send portion without waiting for the peer's close frame to arrive.
Testing the fix for this has uncovered some other issues in the websocket implementation as well.
The text was updated successfully, but these errors were encountered:
RFC 6455 is pretty clear that peers are meant to send a close frame on shutdown, which includes when receiving a close from from a peer.
The idea is that nobody tears down the TCP connection until both sides have received close frames from the other side. (Well sort of ... the second sender can initiate a close once the message is issued and pushed on the wire.)
I'm going to set aside SO_LINGER related issues for the moment and just focus on WS_CLOSE handling.
This was pointed out by @alawn-wang in #1722 - but that PR was a bit incomplete as it only did the send portion without waiting for the peer's close frame to arrive.
Testing the fix for this has uncovered some other issues in the websocket implementation as well.
The text was updated successfully, but these errors were encountered: