cleaning up after a websocket goes aways is not clear about ring HOT 4 CLOSED

I think I was too hasty in assuming just forwarding jetty's onClose wouldn't result in it always getting called, but hard to tell, I haven't found docs that say it is always called, but I found a stackoverflow post that suggested it was (but now have lost the link to that post)

from ring.

Interesting. I hadn't considered how Jetty would behave under those circumstances. Thank for for bringing it to my attention.

My instinct is to adjust the SPEC and say that on-close is guaranteed to be called if and only if on-open is called, as if the WebSocket is not correctly established and never "opened", it makes no sense for it to then be "closed". This seems the most correct behavior, at least to my mind.

With regard to the Jetty documentation on WebSocketConnectionListener, it says that onWebSocketClose is called when "A Close Event was received." Given that the close status includes events where the WebSocket was closed abnormally - i.e. the TCP connection is terminated without a valid close frame - this implies that once open, a close event is guaranteed. However, I can confirm this on the Jetty mailing list to be sure.

from ring.

The Jetty users mailing list confirms that on-close is guaranteed to be called if on-open is: https://www.eclipse.org/lists/jetty-users/msg10694.html

from ring.

interesting, definitely not at all clear to me that "A Close Event was received" in the docs encompasses abnormally termination, but if the jetty mailing list says it is so it must be so. And I didn't realize there was specific reason code to synthesize an onClose call even if no close frame with a reason code came.

from ring.