Re: [hybi] Straw poll: Do you miss interjectable WebSocket level control frame? (was: Re: Discontinuation of mux ...)

[Takeshi Yoshino <[e-mail]>]

On Tue, Feb 25, 2014 at 5:27 PM, Yutaka Hirano <[e-mail]> wrote:

> Shouldn't ws.close() allow queued messages to be flushed before the
>> actual closing?
>
> It is allowed to wait until the endpoint finishes sending the message.
> Is it the desired behavior? I thought it is undesired, but I'm not
> confident now.
>

I think it's underspecified. In the WHATWG WebSocket API spec, close() is
required to "start the WebSocket closing handshake". RFC 6455 neither says
the algorithm may terminate ongoing "Send a WebSocket Message" algorithm
nor says it may not.

----

Even if we allow close to terminate ongoing send, since the sender requests
the termination explicitly and the peer replies to the close with a close
frame after understanding the ongoing send is cancelled, it's fine to call
it as clean close, I think.

There's no way in the WebSocket API to tell that the message it is
receiving has been cancelled to the script, but I don't think it's
problematic. The message sending was clearly cancelled. Both side knows
that. The receiver just won't deliver the cancelled message.

----

But I think there're also needs for graceful close, i.e. to send a message
and do closing handshake after finishing the send. If there's only method
that terminates ongoing send, the user is required to do app level
acknowledgement before calling the method.

My gut feeling is that such a cancellation should be provides as a separate
method and close() should work as a graceful close.

This needs more discussion, but I believe WebSocket users are already used
to graceful behavior.


> On Tue, Feb 25, 2014 at 2:40 PM, Zhong Yu <[e-mail]> wrote:
>
>> On Mon, Feb 24, 2014 at 10:58 PM, Yutaka Hirano <[e-mail]>
>> wrote:
>> >> * Close: Can be used to perform a "clean" close in the middle of
>> sending a
>> >> message. However, I cannot think of any applications that would
>> consider a
>> >> situation in which a in-transit message was aborted to close the
>> connection
>> >> to be a "clean close" scenario.
>> >
>> > An endpoint should be able to cancel the ongoing transmission, i.e. The
>> > close call should abort transferring very_very_long_message in the
>> following
>> > code.
>> >
>> >
>> > ws = new WebSocket(...);
>> > ws.onopen = function() {
>> >   ws.send(very_very_long_message);
>> >   ws.close();
>> > };
>>
>> Shouldn't ws.close() allow queued messages to be flushed before the
>> actual closing?
>
>