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

[Takeshi Yoshino <[e-mail]>]

On Wed, Feb 26, 2014 at 7:05 AM, Takeshi Yoshino <[e-mail]>wrote:

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

Also note that a close frame may be sent unsolicitedly by the peer and may
result in CloseEvent with wasClean set.