Inline ...
Hi,
In researching a PR[1] I noticed that the TCK is attempting to send
messages in message annotated with @OnClose[2] although the associated
client never tests for that message being received (or not being
received) by the client.
I think the tests can be made more robust here but before starting down
that path, I wanted to check that there was consensus on the expected
behaviour in this case:
Is it legal to send/start a new message in a method annotated with @OnClose?
Yes, and many libraries do this to close their own protocols.
Give the following from RFC 6455:
- 6.1 The session must be OPEN to send a message
- 7.1.3 Upon either sending or receiving a Close control frame, it is
said that The WebSocket Closing Handshake is Started and that
the WebSocket connection is in the CLOSING state.
I do not believe it is legal for an endpoint that has received (and
processed) a CLOSE from to attempt to send a DATA frame.
If you receive a CLOSE frame that starts the close handshake, you can still send more frames and even start more messages until your side sends it's CLOSE frame.
This is the half-open scenario.
In the WebSocket API behavior, I expect that once I get a `@OnClose` annotated method called, I have to do everything I need to do before returning from that method call.
Once the @OnClose method call is complete, the following occurs ...
* The local session must close.
* The application could use Session.close() while it's in the @OnClose, for whatever reason it wants to.
Even to change the close status code.
* If the application hasn't issued Session.close(), then the implementation MUST close the websocket session.
If your application initiated the close handshake by sending the CLOSE frame, then you cannot send messages in @OnClose.
- Joakim
