Re: [hybi] Clarify the role of closing handshake

[Greg Wilkins <[e-mail]>]

On 10 February 2011 20:25, Gabriel Montenegro
<[e-mail]> wrote:
> I think your simple reason would be enough (either normal or abnormal close for now).

cool

> 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?

I'm not arguing either way.  I can see the benefits of half close and
flush through, but also the complexities, so I'm happy to follow herd
on this one.

cheers


>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Greg
>> Wilkins
>> Sent: Wednesday, February 09, 2011 17:04
>> To: Takeshi Yoshino
>> Cc: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>
>