Re: [hybi] Clarify the role of closing handshake

I think your simple reason would be enough (either normal or abnormal close for now).

To be clear: you're not arguing against the simplified semantics of considering the websocket closed (no further data or control) upon either sending or receiving a Close message, correct?

> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Greg
> Wilkins
> Sent: Wednesday, February 09, 2011 17:04
> To: Takeshi Yoshino
> Cc: hybi@ietf.org
> Subject: Re: [hybi] Clarify the role of closing handshake
> 
> 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
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi