Re: [hybi] Clarify the role of closing handshake

[Greg Wilkins <[e-mail]>]

One of the other aims of the closing handshake was to better identify
error condition, so as to prevent a client repeating unacceptable
operations.

For example, if a client sends a frame that is too large for the
server to handle, the server needs to indicate that an error condition
has occurred.  If the connection is closed (orderly or otherwise) ,
then the client might assume that it was an idle shutdown or transient
condition on the server and thus open a new connection and continue to
send over large frames.


Currently -05 says:

7.1.2.  Server-initiated closure
   Certain algorithms require or recommend that the server *abort the
   WebSocket connection* during the opening handshake.  To do so, the
   server must simply close the WebSocket connection.


the problem with this is that for a client such a close of the
websocket connection cannot be distinguished from a
network/intermediary failure.   I think that typically an aborted
connection should not be retried, but a network/intermediary failure
should be - so it would be good to be able to signal to the client the
difference.

Thus I'd like to suggest that the close handshake carry a single byte
of reason for the close.
I think it would be sufficient to define just:

  0x00 Normal close
  0x01 Abnormal close

But I could see an argument for something a little richer:

 0x00 Idle close
 0x01 close
 0x02 abnormal close

but I concede that the danger here is trying to define too many close states