TCK: idle timout connection close behavior

[joakime]

Challenged tests
com.sun.ts.tests.websocket.spec.application.closing.WSCClientIT.connectionHasBeenClosedWithStatus1006AfterTimeoutTest

TCK Version
HEAD (likely equivalent of 2.2)

Description
Test expects after a timeout we get a 1006 NO_CLOSE code, but in Eclipse Jetty we send 1001 GOING_AWAY on network for idle timeout, which is what the Autobahn Websocket Test Suite expects.

Additional context
The TCK shouldn't be dictating websocket protocol behaviors, that's for other testing suites to do.
The TCK should be following websocket protocol behavior, and should allow for any of the legitimate close status codes for an idle timeout.

[joakime]

CC @lachlan-roberts

[markt-asf]

The TCK behaviour here looks to be explicitly testing the requirement in section 2.1.5 of the Jakarta WebSocket specification that a 1006 code should be used if the close was initiated locally.

[lachlan-roberts]

RFC6455 says that 1006 means that the connection was closed without sending and receiving a close frame, and in this case an 1001 close frame was sent over the network.

So seems like the Jakarta WebSocket specification is redefining the meaning of this code to mean it was a locally initiated close even though that is not what it means in RFC6455.

There is also the case where we read EOF before sending/receiving a close frame, onClose will be called with 1006 to indicate no close frame was sent or received, but the close was not initiated locally as suggested in the Jakarta WebSocket spec.

So the 1006 will not be able to be used to reliably determine whether it was a locally initiated closure or not.

[volosied]

To recap, the Jakarta WebSocket specification explicitly says:

If the close was initiated by the local container, for
example if the local container determines the session has timed out, the local implementation must use
the WebSocket protocol close code 1006 (a code especially disallowed in close frames on the wire), with
a suitable close reason. That way the endpoint can determine whether the close was initiated remotely
or locally. If the session is closed locally, the implementation must attempt to send the WebSocket close
frame prior to calling the onClose() method of the WebSocket endpoint.

The spec uses a session timeout as an example. As described by this challenge, it seems to potentially contradict RFC6455.

 1006 indicates an abrupt closure, but, a session timeout doesn’t necessarily seems abrupt? It was controlled closure due to a lack of activity. Therefore, 1001 makes sense as it’s going away.


Proposal:
Instead of using an example, the specification should explicitly define behavior for timeouts. Can the spec be updated to allow 1001 for session timeouts in order to align with the RFC?

However, considering that 1006 has been used in practice for years, should the 1006 still also be allowed, as optional or deprecated? The Jakarta spec can continue to call that that 1006 is a code which disallows close frames on the wire.



TCK would also check for both.

Thoughts?

[lachlan-roberts]

I think this paragraph should be removed from the Jakarta spec

If the close was initiated by the local container, for example if the local container determines the session has timed out, the local implementation must use the WebSocket protocol close code 1006 (a code especially disallowed in close frames on the wire), with a suitable close reason. That way the endpoint can determine whether the close was initiated remotely or locally. If the session is closed locally, the implementation must attempt to send the WebSocket close frame prior to calling the onClose() method of the WebSocket endpoint.

1. 1006 semantics are fixed by RFC6455; to "indicate that the connection was closed abnormally, e.g., without sending or receiving a Close control frame".
2. Whether the close was initiated locally or remotely cannot be inferred from 1006. You can see 1006 in both locally and remotely initiated terminations whenever no Close frame is observed.

However, considering that 1006 has been used in practice for years, should the 1006 still also be allowed, as optional or deprecated? The Jakarta spec can continue to call that that 1006 is a code which disallows close frames on the wire.

I don't think the Jakarta spec should say 1006 is allowed in this case because it would violate the definition of 1006 in RFC6455. But if a timeout occurred it could still result in a 1006 status code if the WebSocket close handshake could not be completed.

[markt-asf]

I'm not seeing anything wrong with the use of 1006 in onClose() as per the TCK test. The test is checking that the server endpoint saw a 1006 close code in onClose() which is as expected. I too would expect to see 1001 on the wire (and I'm not seeing anything in the TCK test that would prevent that). I do agree that local vs remote is not a correct interpretation of 1006. There are cases where an abnormal closure could be triggered remotely (e.g. by receiving a TCP reset).

I would support updating the text in 2.1.5 along the following lines:

• If a close frame is received from the remote peer then the close code from that close frame must be used when calling onClose()
• If the local application initiates the close then onClose() must be called using the close code specified by the application
• If the session is closed abnormally (e.g. session timeout, broken network connection) then onClose() must be called with 1006 as the close code.

That last point could be argued to always be a local closure since the local WebSocket container is making the decision to declare the session closed and calling onClose() but I'd rather avoid having to argue/explain that and just (slightly) redefine when onClose() will be called with 1006 as outlined above to remove the local/remote discussion.

[lachlan-roberts]

I'm not seeing anything wrong with the use of 1006 in onClose() as per the TCK test. The test is checking that the server endpoint saw a 1006 close code in onClose() which is as expected.

But why is this expected?

https://www.rfc-editor.org/rfc/rfc6455.html#section-7.1.5

The WebSocket Connection Close Code is
defined as the status code (Section 7.4) contained in the first Close
control frame received by the application implementing this protocol.
If this Close control frame contains no status code, The WebSocket
Connection Close Code is considered to be 1005. If The WebSocket
Connection is Closed and no Close control frame was received by the
endpoint (such as could occur if the underlying transport connection
is lost), The WebSocket Connection Close Code is considered to be 1006.

So if a timeout occurs and the Server both sends and receives a 1001 Close Frame, then it should be a 1001 close status code reported in onClose().

But if the server sends the 1001 Close Frame and then immediately aborts the connection without waiting for a close frame response, then the close code reported in onClose() should be 1006.

So I think its fine for the Jakarta spec to mandate that 1001 should be sent in the case of a timeout. But I don't think it should override the close code semantics of RFC6455.

[volosied]

Thinking out load -- is the connection 'closed' or 'terminated' during a timeout? If the latter, then 1006 is appropriate. But it's simply closed, I don't see why 1001 shouldn't be used.

[joakime]

Think about the 2 main timeout scenarios.

1. The local times out before the remote.
2. The remote times out before local.

In both cases the connection is still valid before timeout.
In both cases the timeout just closes the connection with an indicator (1001 status code for "going away") that it is being closed due to timeout.

As for the conceptual difference of "close" or "terminate", there's no difference.
If you look at the listed status codes (https://www.rfc-editor.org/rfc/rfc6455.html#section-7.4) then you'll see that some close status codes are sent that indicate the connection is terminating.

[volosied]

To clarify, by terminated, I should have meant that the TCP connection was cut abruptly -- no closing frame sent. Perhaps not the right word since the RFC also uses terminating in the various status codes. I was looking at a node websocket for comparison and saw there was a close (graceful) and a terminate (immediately destroy) method calls. I may be over thinking it here.

Another suggestion, can we overload setMaxIdleTimeout(long milliseconds) to allow developers to set which status code should be sent with a timeout? There can be validation to ensure they don't set a reserved status code.

Edit: If nothing is set, then perhaps the socket/connection can be forcefully cut resulting in a 1006? Otherwise, gracefully close the connection with the desired status code - 1001 or something else indicating an idle session timeout.

[markt-asf]

But why is this expected?

Because the Jakarta WebSocket spec says that is what should happen.

So if a timeout occurs and the Server both sends and receives a 1001 Close Frame, then it should be a 1001 close status code reported in onClose().

But if the server sends the 1001 Close Frame and then immediately aborts the connection without waiting for a close frame response, then the close code reported in onClose() should be 1006.

That won't work. The Javadoc for onClose() requires it is called "immediately prior to the session with the remote peer being closed" so the close code used in that call can't depend on the outcome of sending the close frame.

So I think its fine for the Jakarta spec to mandate that 1001 should be sent in the case of a timeout. But I don't think it should override the close code semantics of RFC6455.

It doesn't. RFC6455 defines what happens on the wire. The Jakarta WebSocket spec doesn't change that. The 1006 is only used at the application layer and is intended as a signal to the application that the close was initiated by the container rather than an endpoint. In the case of a timeout, I'd still expect to see 1001 on the wire. But I would expect to see 1006 in onClose().

Is the position being advocated here that onClose() shouldn't use 1006 to signal that the container (rather than endpoint) initiated close? If so, that would be a breaking change to the WebSocket spec and require a 3.0 - which isn't currently the plan for Jakarta EE 12. But we can change the plan if there is consensus to do so.

[volosied]

I'd still expect to see 1001 on the wire. But I would expect to see 1006 in onClose().

It seems odd to report a 1006 to the application and yet send a 1001 over the wire. Does the closing handshake still occur? Does the application need to know the connection was closed by the container, not the peer? 1006 could still be used if the peer never replied after sending the 1001. Doesn't 1006 make more sense if the remote closed abruptly?

The spec also says:

If the session is closed locally, the implementation must attempt to send the WebSocket close
frame prior to calling the onClose() method of the WebSocket endpoint.

This seems to support having the container to try to send a 1001. I suppose the keyword here is attempt if the connection is still active (which it should be, hopefully).

Should the wording immediately prior to the session with the remote peer being closed be changed? Can't the session object stay active for a little longer? The javadoc already mentions that sends shouldn't occur during onClose. If there's a grace period after sending the closing frame, shouldn't we report a 1001 and 1006 based on whether the closing handshake was successful or not?

Is the position being advocated here that onClose() shouldn't use 1006 to signal that the container (rather than endpoint) initiated close?

I'll have to defer to @joakime and @lachlan-roberts.

---

Edit:

1.4. Closing Handshake
... Upon receiving such a frame, the other peer sends a
Close frame in response, if it hasn't already sent one. Upon
receiving that control frame, the first peer then closes the
connection

When the closing frame is received, the onClose method can then be called before the connection is closed. That would comply? Can't 1001 (or another status) still be reported then? Then again, this goes back to 1006 indicating the container closed the connection. If that 1006 timeout example text was removed from the web socket specification, this there any need to worry about a 1006 unless no closing frame is used?