Re: [websocket-dev] Connection closure behaviour

[Mark Thomas <markt@xxxxxxxxxx>]

On 10/07/2020 19:15, Joakim Erdfelt wrote:
> inline ...
> 
> On Fri, Jul 10, 2020 at 12:04 PM Mark Thomas <markt@xxxxxxxxxx
> <mailto:markt@xxxxxxxxxx>> wrote:
> 
>     On 10/07/2020 17:06, Joakim Erdfelt wrote:
>     > On Fri, Jul 10, 2020 at 10:38 AM Mark Thomas <markt@xxxxxxxxxx
>     <mailto:markt@xxxxxxxxxx>
>     > <mailto:markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>>> wrote:
> 
>     <snip/>
> 
>     >     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.
> 
>     But that is not what RFC 6455 says. 7.1.3 specifically states sending or
>     *receiving* a close control frame moves the WebSocket connection state
>     to CLOSING and 6.1 requires the connection state to be OPEN in order to
>     send a message.
> 
>     The phrase "half-open" does not appear anywhere I could find in RFC
>     6455.
> 
>     What am I missing in RFC 6455 that allows / supports the concept of a
>     half-closed connection?
> 
> 
> The moving from OPEN to CLOSING is a protocol behavior that your
> implementation should do when it's appropriate.
> 
> But your API and Implementation can choose when to do that.
> 
> Yeah, this is all interpretation.
> The [hybi] list has a long history of discussing this, even from the
> earliest drafts in 2009.

Hmm.

It comes down how you read "Upon ... receiving a Close control frame".

It is certainly implementable if you read that as "Receive Close frame,
call @OnClose, send close frame" and allow data frames up to the point
where the close frame is sent. But that does seem to be stretching the
definition rather.

> Jetty moves from OPEN to CLOSING after @OnOpen is called and returns.
> And moves from CLOSING to CLOSED once the closing handshake is complete.
> When not in OPEN state, attempts to write fail.

What is the sequence when Jetty receives a close message?

Tomcat is currently:
- prevent further DATA frames
- send the close message
- call @OnClose

I'm guessing Jetty is different.

I'm not at all adverse to relaxing Tomcat's implementation (assuming the
other committers agree) as it should be a non-breaking change.

What I really want to do is get a clear definition of what this group
thinks should happen, update the WebSocket spec to define the expected
behaviour more clearer and then update the TCK to test for it. Which may
well need to wait until 2.1.

> The WebSocket Proxy scenario shows this to be the most flexible choice
> and still within the confines of protocol spec.
> 
> I believe there's tests for this in the autobahn websocket testsuite.
> (but i could be remembering incorrectly).

>From memory the Autobahn tests for servers relies on the server echoing
back DATA messages so I don't think it can test a lot of the edge cases
here.

I know Tomcat passes the Autobahn tests which also makes me think a lot
of this won't be tested else I'd expect Tomcat to fail some tests based
on this conversation.

Mark