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
cleaning up after a websocket goes aways is not clear #505
Comments
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) |
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 With regard to the Jetty documentation on WebSocketConnectionListener, it says that |
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 |
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. |
the spec says on-close is guaranteed to be called and can be used for finalization logic.
if you run a little ring-jetty server like:
and then hit it with curl like
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" http://localhost:4395
you get some interesting behavior:With some thought you can come to the conclusion that the fact that on-open was never called is the signal to the handler that the websocket is not valid, but that is not at all clear from the spec, and the spec for on-close doesn't say it is guaranteed to be called if on-open is called, it just says it is guaranteed to be called.
Additionally the jetty websocket impl just forwards the jetty WebSocketListener onClose events to the handler's on-close function, and there is nothing in the docs for WebSocketListener that says onClose is guaranteed to be called. I don't have a reproducer at the moment, but I believer it should be relatively straightforward to replicate, and that it happens a lot in practice, that sometimes when the underlying tcp connection is closed, onClose is never called and there are no exceptions.
The text was updated successfully, but these errors were encountered: