Re: [hybi] Clarify the role of closing handshake

[Brodie Thiesfield <[e-mail]>]

2011/2/16 Ian Fette (イアンフェッティ) <[e-mail]>:
> I am trying to get out a -06 that resolves some of the CLOSE issues, but
> currently I'm getting caught up by a few other things at work today.
> What I'm currently looking at is this: (comments welcome)
>          <t>The Close message contains an opcode of 0x01.</t>
>           <t>The Close message contains no body (the body has zero
> length).</t>
>           <t>The application MUST NOT send any more data messages after
> sending
>           a close message.</t>
>           <t>If an endpoint receives a Close message and that endpoint did
> not
>           previously send a Close message, the endpoint MUST send a Close
>           message in response. It SHOULD do so as soon as is practical.
>           </t>
>           <t>After both sending and receiving a close message, an endpoint
>           considers the websocket connection closed, and
>           SHOULD close the underlying TCP connection.</t>
>           <t>If a client and server both send a Close message at the same
> time,
>           both endpoints will have sent and received a Close message and
> should
>           consider the websocket connection closed and close the underlying
>           TCP connection.</t>

I would like to see support in the close message for a status
code/reason to show the reason for an abnormal close. The goal is
purely to provide useful information for interop troubleshooting.

At the moment the spec has a number of cases where the connection is
just dropped with no information provided to the peer as to why.
Although from the normal operation of the server this may be optimal,
it is going to make integration testing hell. There needs to be some
way to find out why the remote server is dropping the connection.

I propose that the close message contain a status code and an optional
message. Further, I propose that the peer that following a successful
handshake, the peer that is about to abort the connection SHOULD send
a close message with a valid status code and optionally a more
detailed human readable message. This is valid for both client and
server aborts (i.e. the client is aborting because of an invalid
opcode/incorrectly formatted server message).

An example of the text that I am suggesting, modifying the relevant
bits of what you supplied.

----
The Close message contains an opcode of 0x01.The Close message
contains a body made up of a status code and an optional
human-readable message following the format:

  status = [123] [0-9] [0-9]
  msg    = SP CHAR+
  close  = status msg

The status code ranges are 1xx normal, 2xx message sender error, 3xx
message receiver error.

The application MUST NOT send any more data messages after sending a
close message.
----

If a reply Close message is required as per Ian's text, then I would
modify it as:
----
If an endpoint receives a Close message and that endpoint did not
previously send a Close message, the endpoint MUST send a Close
message with a 100 status (normal close) in response. It SHOULD do so
as soon as is practical.
----

The text on aborts would be changed to note that an abort is actually
a Close with abnormal status + close of transport. If a close message
requires a close reply then the aborting peer would need to wait
around to receive that message (or at least drain the socket to avoid
TCP problems).

Suggested status codes (trying to not get too detailed):

  1xx  Normal close range
    100  Normal close

  2xx  Message sender error range
    200  Message sender general error
    201  Invalid opcode
    202  Invalid framing (e.g. RSV bits used but not negotiated,
fragmented control msg)
    203  Invalid encoding (e.g. invalid UTF-8)

  3xx  Message receiver error range
    300  Message receiver internal error
    301  Overloaded / service unavailable
    302  Message too long (i.e. longer than this server/intermediatary supports)

Regards,
Brodie