Subject: [hybi] Close frame from webbrowser after close frame from server

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Aug 2011 14:26:39 +0200

Hi, my WS server (just starting it) does not terminate the TCP
connection after sending a "close" frame to the client.

I've realized that Google Chrome 15.0.854.0-dev sends a "close" frame
upon receipt a "close" frame from the WS server and then the browser
closes the TCP connection., but Firefox 8 does not send such "close"
frame and directly closes the TCP connection.

As per WS specification both seem valid behaviors but, shouldn't the
spec mandate (or make more recommended) a more specific behaviour?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 23 Aug 2011 03:23:58 +0900

Hi,

> spec mandate (or make more recommended) a more specific behaviour?

5th paragraph of this section tells us to do so.
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-4.5.1

Chrome 15.0.854.0 does so. We've implemented it as specified there.

Firefox 8.0a2 (2011-08-22) also responds server initiated close frame before
closing TCP here against pywebsocket.

...
03:18:14.756457 IP pywebsocket > Fx8: Flags [P.], seq 130:134, ack 498, win
54, length 4
(snip)
        0x0030:  0036 e2cb 0000 8802 03e8                 .6........
03:18:14.756835 IP Fx8 > pywebsocket: Flags [P.], seq 498:506, ack 134, win
16391, length 8
(snip)
        0x0030:  4007 818a 0000 8882 d59e a784 d676       @............v
...

Here, 0xd59e XOR 0xd676 is 1000 in decimal.

Thanks,
Takeshi

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Aug 2011 20:38:58 +0200

> closing TCP here against pywebsocket.

I have Firefox 9.0a1 (2011-08-19) and does not send the close frame
when it receives a close frame. Google 15.X does it.
I will recheck however.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 22 Aug 2011 11:49:09 -0700

As far as I understand you describe the behavior of Chrome/FF in response to
a server initiated close frame as part of a graceful closing handshake.

However, there is a 2nd scenario where both user agents currently don't appear
to send close frames, namely upon failing the connection, i.e. because of
receiving a frame with reserved opcode in the absence of extensions negotiated.

The spec says SHOULD though.

Chrome at least reports the error (i.e. reserved opcode) in JS, but - as FF - won't send
a close. Is that by design?

7.1.7.  Fail the WebSocket Connection

   Certain algorithms and specifications require an endpoint to _Fail
   the WebSocket Connection_.  To do so, the client MUST _Close the
   WebSocket Connection_, and MAY report the problem to the user (which
   would be especially useful for developers) in an appropriate manner.

   If _The WebSocket Connection is Established_ prior to the point where
   the endpoint is required to _Fail the WebSocket Connection_, the
   endpoint SHOULD send a Close frame with an appropriate status code
   Section 7.4<http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-7.4> before proceeding to _Close the WebSocket Connection_.
   An endpoint MAY omit sending a Close frame if it believes the other
   side is unlikely to be able to receive and process the close frame,
   due to the nature of the error that led to the WebSocket connection
   being failed in the first place.  An endpoint MUST NOT continue to
   attempt to process data (including a responding Close frame) from the
   remote endpoint after being instruted to _Fail the WebSocket
   Connection_.

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Takeshi Yoshino
Gesendet: Montag, 22. August 2011 20:24
An: Iñaki Baz Castillo
Cc: [email-masked]
Betreff: Re: [hybi] Close frame from webbrowser after close frame from server

Hi,

On Mon, Aug 22, 2011 at 21:26, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:
As per WS specification both seem valid behaviors but, shouldn't the
spec mandate (or make more recommended) a more specific behaviour?

Firefox 8.0a2 (2011-08-22) also responds server initiated close frame before closing TCP here against pywebsocket.

...
03:18:14.756457 IP pywebsocket > Fx8: Flags [P.], seq 130:134, ack 498, win 54, length 4
(snip)
        0x0030:  0036 e2cb 0000 8802 03e8                 .6........
03:18:14.756835 IP Fx8 > pywebsocket: Flags [P.], seq 498:506, ack 134, win 16391, length 8
(snip)
        0x0030:  4007 818a 0000 8882 d59e a784 d676       @............v
...

Thanks,
Takeshi

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 23 Aug 2011 04:39:27 +0900

On Tue, Aug 23, 2011 at 03:49, Tobias Oberstein <[email-masked]
> wrote:

> As far as I understand you describe the behavior of Chrome/FF in response
> to****
>

Yes.

> **
>
> However, there is a 2nd scenario where both user agents currently don't
> appear****
>
> to send close frames, namely upon failing the connection, i.e. because of*
> ***
>
> receiving a frame with reserved opcode in the absence of extensions
> negotiated.****
>
> ** **
>

Yes, it's SHOULD. Since after seeing broken frame from the other peer, it
doesn't make much sense to wait for close in response to perform graceful
shutdown, the close initiator doesn't have to wait for close in response (in
the spec, "have to wait" is "MUST NOT process"). Then, as we give up
graceful shutdown, even the first close frame is not really necessary, but
SHOULD be sent since close code/reason might be informative for the other
peer.

So, though it's required in the spec, endpoints don't need to reply close
frames resulted from _Fail the... algorithm. But now graceful closing
handshake may carry any code/reason. Endpoints cannot determine if a certain
close frame is for _Fail the.. or for _Start the WebSocket Closing....

We may group codes into ones require response and ones not, but I don't see
much gain from that effort.

I think it's fine to just require endpoints to respond to a close frame
assuming it's one for _Start WebSocket Closing Handshake_.

Thanks,
Takeshi

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 23 Aug 2011 16:59:33 +0200

> when it receives a close frame. Google 15.X does it.

It was a bug in my WS server which was sending incorrectly the close frame.

-- 
Iñaki Baz Castillo
<[email-masked]>