Subject: [hybi] Conflicting texts about which endpoint should close TCP first

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 5 Nov 2014 14:32:55 +0900

FYI,

https://tools.ietf.org/html/rfc6455#section-1.4

This section says "Upon receiving _that_ control frame, the first peer then
closes the connection". I think the main purpose of the text is to explain
the role of the closing handshake that is to prevent RST hazard, but this
can be also viewed as suggesting that the initiator of closing handshake
should close the underlying connection.

https://tools.ietf.org/html/rfc6455#section-7.1.1

This section recommends that client-side should wait for server-side to
close the TCP connection (with some timeout) to have the server hold the
TIME_WAIT state.

1.4 is non-normative while 7.1.1 is normative.

Chrome had code to follow 7.1.1 but there're some server implementations
that don't close the TCP connection by themselves if they didn't initiate a
closing handshake. This led to keeping connection live for long time
needlessly.

If we fire a CloseEvent strictly following the definition of _The WebSocket
Connection is Closed_ (defined as the time when TCP is closed) and the
WebSocket API spec, a CloseEvent is fired after the needlessly long time
though closing handshake is already finished.

---

From: Kevin <[email-masked]>
Date: Wed, 05 Nov 2014 10:52:43 -0500

On 11/5/2014 12:32 AM, Takeshi Yoshino wrote:
> This section says "Upon receiving _that_ control frame, the first peer 
> then closes the connection". I think the main purpose of the text is 
> to explain the role of the closing handshake that is to prevent RST 
> hazard, but this can be also viewed as suggesting that the initiator 
> of closing handshake should close the underlying connection.
>
> This section recommends that client-side should wait for server-side 
> to close the TCP connection (with some timeout) to have the server 
> hold the TIME_WAIT state.
>
> Chrome had code to follow 7.1.1 but there're some server 
> implementations that don't close the TCP connection by themselves if 
> they didn't initiate a closing handshake. This led to keeping 
> connection live for long time needlessly.
>
> If we fire a CloseEvent strictly following the definition of _The 
> WebSocket Connection is Closed_ (defined as the time when TCP is 
> closed) and the WebSocket API spec, a CloseEvent is fired after the 
> needlessly long time though closing handshake is already finished.
>
>
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
I firmly believe that it is more secure if the client drops connection 
first.  The server should be free to listen for other connections.  In 
my view, clients can crash if the server drops connection first.  I 
don't mean to say that this is always the case, but it happens.

-- 
Kevin