a whole websoceket connection when close

[alawn-wang]

fixes #
A whole websocket connection should send a close frame when received a close frame.
This is a standard in RFC6455 chapter 5.5.1.https://datatracker.ietf.org/doc/html/rfc6455#section-5.5.1

[gdamore]

I don't think this is quite correct. Because otherwise we would get into a ping pong loop of close frames. But yes the code as it stands does not conform to the RFC.

I will look more closely to verify whether my concern is correct.

[alawn-wang]

Ok, I know what you mean. If it's closed normally, it won't have this problem. Because when it first received the close-frame, the 'ws->close' will be change as 'true' in 'ws_send_close()'. when you second received the close frame again, it won't send close-frame again.

[gdamore]

I've gone back and looked and I'm still concerned, although it's different now.

My specific concern here is that it is possible for the TCP connection to be left dangling. The logic I had before was to send the close, and really we should linger for that, and then close the session entirely. It looks to me like instead the existing code was waiting for the received reply. Which is wrong too.

The logic needs to be changed as thus (pseudo code):

rx callback: if frame is close, then
if already sent close, its a reply, just close the socket
else send close, with timeout

tx callback: if frame is close, then
if already received close, then just close socket
else wait for receive close, with timeout

if timeout (either send or recv) fires, just close the socket.

If I get some time this weekend I'll see if I can put that together.

[gdamore]

This will almost certainly leave dangling TCP connections. Please see my other comments.

[gdamore]

I do btw recall deciding it was ok to break from the specification on this item, but now I think that was misguided. We should implement the spec properly.

[gdamore]

I've fixed this entirely. I'm declining this PR as a result.