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

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 19 Feb 2014 13:19:18 +0900

It seems we're using "RFC 6455 Semantics" with a bit different nuance. I'd
like to divide the discussion into more primitive questions.

The second point I want to hear your opinion is: "do you miss interjectable
WebSocket level control frame?"

Since RFC 6455's control frames can be interjected in the middle of a data
message, to keep this as-is, we need to prevent FRAME boundary from being
modified by multiplexing mechanism. Possible solutions are:
- encapsulate WebSocket frame
- prepare some mechanism (HTTP/2.0 frame type) in HTTP/2.0 layer similar to
HTTP/2.0 PING frame that provides a box to which we can map WebSocket level
control (PING/PONG/CLOSE/and other reserved control opcodes)

Please respond to this thread with your answer and rationale.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 19 Feb 2014 13:24:06 +0900

I'm inclined to say "Yes" for this question so said yes for #2 of Yutaka's
original question [1], but I could also cope with if we decide to drop this.

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg10403.html

---

From: Adam Rice <[email-masked]>
Date: Wed, 19 Feb 2014 16:09:16 +0900

With the current set of control frames, I would not miss the ability to
interject them in the middle of a data message.

Breaking them down one by one:

* Pong: useless in the middle of a data message (the peer already knows
that it is receiving data, and useless for RTT measurement because it has
an unknown amount of OS queueing and buffer bloat in front of it).
* Ping: almost always useless in the middle of a data message. It could be
useful if, for example, you had a middle box which closed "idle"
connections, and considered any connection "idle" if there was no TCP/IP
payload traffic originating from the client, and the server was in the
middle of sending a huge message. However, such a middle box would also
break HTTP downloads so seems unlikely to exist in practice. Even if it
existed, how would the server detect it to know that it needed to send a
Ping?
* 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.

On 19 February 2014 13:24, Takeshi Yoshino <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 19 Feb 2014 03:45:52 -0800

>The second point I want to hear your opinion is: "do you miss interjectable WebSocket level control frame?"

>Since RFC 6455's control frames can be interjected in the middle of a data message, to keep this as-is, we need to prevent FRAME boundary from being modified by multiplexing mechanism. Possible solutions are:
>- prepare some mechanism (HTTP/2.0 frame type) in HTTP/2.0 layer similar to HTTP/2.0 PING frame that provides a box to which we can map WebSocket level control (PING/PONG/CLOSE/and other reserved control opcodes)

>Please respond to this thread with your answer and rationale.

I don't think this should be removed from RFC6455.

The extension mechanisms of RFC6455 allow for flexible design of WebSocket extensions. Being able to interject existing and new control messages, and to interleave multiple data messages is part of that flexibility.
 
Also: there seems to be an outburst of "lets remove X" from RFC6455 initiatives lately.

Not sure, but it's my impression that these are all related to the desire for some kind of WebSocket-over-HTTP2 protocol. And more so: to mold RFC6455 so that it "fits into HTTP2".

I don't agree with that approach. I think HTTP2 should take WebSocket "as is", if it wants to act as a transport instead of attempting to redefine it. Or define it's own messaging (not bound by WS).

/Tobias

---

From: Francis Brosnan Blazquez <[email-masked]>
Date: Wed, 19 Feb 2014 17:59:10 +0100

Hi Tobias,

> The extension mechanisms of RFC6455 allow for flexible design of
> WebSocket extensions. Being able to interject existing and new control
> messages, and to interleave multiple data messages is part of that
> flexibility.
>  
> Not sure, but it's my impression that these are all related to the
> desire for some kind of WebSocket-over-HTTP2 protocol. And more so: to
> mold RFC6455 so that it "fits into HTTP2".
> 
> I don't agree with that approach. I think HTTP2 should take WebSocket
> "as is", if it wants to act as a transport instead of attempting to
> redefine it. Or define it's own messaging (not bound by WS). 

+1

I couldn't express it better, plus the fact it took a long road to reach
RFC6455....*and*
there's a lot of software out there running on production env assuming
current WS
definition.

Best Regards,

---

From: Roberto Peon <[email-masked]>
Date: Wed, 19 Feb 2014 11:35:58 -0800

If they're not used, and implementors don't have plans to use them however,
they should be removed.
As we learned from HTTP/1.1, parts of the spec which are not exercised are
likely to cause problems later.
-=R

On Wed, Feb 19, 2014 at 3:45 AM, Tobias Oberstein <
[email-masked]> wrote:

> >The second point I want to hear your opinion is: "do you miss
> interjectable WebSocket level control frame?"
>
> >Since RFC 6455's control frames can be interjected in the middle of a
> data message, to keep this as-is, we need to prevent FRAME boundary from
> being modified by multiplexing mechanism. Possible solutions are:
> >- prepare some mechanism (HTTP/2.0 frame type) in HTTP/2.0 layer similar
> to HTTP/2.0 PING frame that provides a box to which we can map WebSocket
> level control (PING/PONG/CLOSE/and other reserved control opcodes)
>
> The extension mechanisms of RFC6455 allow for flexible design of WebSocket
> extensions. Being able to interject existing and new control messages, and
> to interleave multiple data messages is part of that flexibility.
>
> Not sure, but it's my impression that these are all related to the desire
> for some kind of WebSocket-over-HTTP2 protocol. And more so: to mold
> RFC6455 so that it "fits into HTTP2".
>
> I don't agree with that approach. I think HTTP2 should take WebSocket "as
> is", if it wants to act as a transport instead of attempting to redefine
> it. Or define it's own messaging (not bound by WS).
>
> /Tobias
>

---

From: Adam Rice <[email-masked]>
Date: Thu, 20 Feb 2014 13:44:33 +0900

Since interjectable control frames are implemented and in active use, I
don't think they should be removed from the successor to RFC6455.

My answer was purely in respect to the question of "would I miss them if
they were gone", to which my answer is no.

On 20 February 2014 04:35, Roberto Peon <[email-masked]> wrote:

> If they're not used, and implementors don't have plans to use them
> however, they should be removed.

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 25 Feb 2014 01:53:56 +0900

Thanks all.

Sorry for not being clear. As you see by looking at the title, this is
branch of the mux discussion thread. I asked this question in the context
of WebSocket/HTTP/2.0 discussion. Not to think of removal of the feature on
the next version of the raw WebSocket Protocol. Please note that. Thanks.

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 25 Feb 2014 07:35:44 +0900

> it. Or define it's own messaging (not bound by WS).

I want to understand what you mean by this, Tobias, and maybe Peter.

As one of Chromium developers, I just want to build and use a scalable
transport for the WebSocket API. For this goal, it doesn't matter whether
HTTP/2.0 works as a transparent transport or not. There's no such
implication in the term "WS/HTTP/2.0" at least when used by me.

What Roberto and Martin are suggesting sounds like one to be categorized as
"define it's own messaging". Some of Yutaka's plans, too. What's your
actual position for them. Not the best option for you but not against?

---

From: Yutaka Hirano <[email-masked]>
Date: Tue, 25 Feb 2014 13:58:53 +0900

> 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();
};

It is possible to _Close the WebSocket connection_ without the closing
handshake in such cases, but since the WebSocket API doesn't expose the
transmission status, doing so makes the closing handshake completely
unreliable.

On Wed, Feb 19, 2014 at 4:09 PM, Adam Rice <[email-masked]> wrote:

>> I'm inclined to say "Yes" for this question so said yes for #2 of
>> Yutaka's original question [1], but I could also cope with if we decide to
>> drop this.
>>

---

From: Zhong Yu <[email-masked]>
Date: Mon, 24 Feb 2014 23:40:56 -0600

On Mon, Feb 24, 2014 at 10:58 PM, Yutaka Hirano <[email-masked]> wrote:
> close call should abort transferring very_very_long_message in the following
> code.
>
>
> ws = new WebSocket(...);
> ws.onopen = function() {

Shouldn't ws.close() allow queued messages to be flushed before the
actual closing?

>> that it is receiving data, and useless for RTT measurement because it has an
>> unknown amount of OS queueing and buffer bloat in front of it).

---

From: Yutaka Hirano <[email-masked]>
Date: Tue, 25 Feb 2014 17:27:15 +0900

> Shouldn't ws.close() allow queued messages to be flushed before the

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.

On Tue, Feb 25, 2014 at 2:40 PM, Zhong Yu <[email-masked]> wrote:

> following

---

From: "Arman Djusupov" <[email-masked]>
Date: Tue, 25 Feb 2014 14:31:29 +0200

Takeshi,

I assume that Tobias means that HTTP/2 should tunnel the WebSocket transport “as is” without stripping off the WebSocket headers or functionality. If so then I am in agreement with Tobias.

I can’t think of a good reason why can’t we just forward a complete WS frame with its full header through the HTTP/2. If I missed an argument that was put forward in a previous discussions please do point me to it. IMO plain tunneling, just like HTTP is tunneled through TLS, would do fine.

If we strip off almost the entire frame header and we fragment the payload so that it is carried by an HTTP/2 frame, we are practically creating a new protocol. Such a protocol doesn’t really need to be related to WebSocket, however (if we do create this new protocol) it can be transparently exposed through the same browser WS API when HTTP/2 is available.

With best regards,

Arman

From: hybi [mailto:[email-masked]] On Behalf Of Takeshi Yoshino
Sent: Tuesday, February 25, 2014 12:36 AM
To: Tobias Oberstein
Cc: [email-masked]; Yutaka Hirano; Peter Thorson
Subject: Re: [hybi] Straw poll: Do you miss interjectable WebSocket level control frame? (was: Re: Discontinuation of mux ...)

On Wed, Feb 19, 2014 at 8:45 PM, Tobias Oberstein <[email-masked]> wrote:

As one of Chromium developers, I just want to build and use a scalable transport for the WebSocket API. For this goal, it doesn't matter whether HTTP/2.0 works as a transparent transport or not. There's no such implication in the term "WS/HTTP/2.0" at least when used by me.

What Roberto and Martin are suggesting sounds like one to be categorized as "define it's own messaging". Some of Yutaka's plans, too. What's your actual position for them. Not the best option for you but not against?

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 26 Feb 2014 04:11:21 +0900

Hi Arman,

On Tue, Feb 25, 2014 at 9:31 PM, Arman Djusupov <[email-masked]> wrote:

> Takeshi,
>
>
>
> I assume that Tobias means that HTTP/2 should tunnel the WebSocket
> transport “as is” without stripping off the WebSocket headers or
> functionality. If so then I am in agreement with Tobias.
>

I understand this argument. For developers who've built and are already
using RFC 6455 based infrastructure, this approach is very simple and
allows for faster and easier migration.

>
>
> I can’t think of a good reason why can’t we just forward a complete WS
> frame with its full header through the HTTP/2. If I missed an argument
> that was put forward in a previous discussions please do point me to it.
> IMO plain tunneling, just like HTTP is tunneled through TLS, would do
> fine.
>

Please search for Roberto's posts in the HyBi archive [1] and Roberto and
Martin's posts to topics including "WebSocket" in httpbis archive [2].
Basically, for those who haven't deployed RFC 6455 based software but
(planning to) introducing HTTP/2.0, inheriting RFC 6455 architecture
provides no benefit but some design points of RFC 6455 considered to be
harmful rather motivate them to throw away RFC 6455 and redesign messaging
architecture inside HTTP/2.0 that can be applied to the WS API. Another
Roberto's point is that basic messaging units and meta data should be
easily recognized and investigated by load balancers with least knowledge
in addition to HTTP/2.0. Clearly separated thinner layering provides
flexibility but also requires more code and tests.

>
>
> If we strip off almost the entire frame header and we fragment the payload
> so that it is carried by an HTTP/2 frame, we are practically creating a
> new protocol. Such a protocol doesn’t really need to be related to
> WebSocket, however (if we do create this new protocol) it can be transparently
> exposed through the same browser WS API when HTTP/2 is available.
>
>
>

Yes. I just want to deliver some protocol that is scalable under the
browser WS API. Whether it's related to the WebSocket Protocol or not does
not matter so much. Since we don't want to implement two or more protocol
in Chromium to achieve the same goal (multiplexed protocol for WS API), we
need to choose one.

There seems to be disjoint between the two parties. I understand both
argument but need to find some landing point.

[1] http://www.ietf.org/mail-archive/web/hybi/current/maillist.html
[2] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 26 Feb 2014 07:05:00 +0900

> Is it the desired behavior? I thought it is undesired, but I'm not

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.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 26 Feb 2014 07:08:36 +0900

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

> On Tue, Feb 25, 2014 at 5:27 PM, Yutaka Hirano <[email-masked]>wrote:
>
> 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.
>

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

---

From: Zhong Yu <[email-masked]>
Date: Tue, 25 Feb 2014 18:54:16 -0600

To be certain that data is delivered, app needs to perform lingering
close by itself, by polling bufferedAmount, and only call close()
after it reaches 0.

This is strange, due to the flaw that send() is an async method but
without a way to registered a callback.

Zhong Yu

On Tue, Feb 25, 2014 at 4:05 PM, Takeshi Yoshino <[email-masked]> wrote:
> the algorithm may terminate ongoing "Send a WebSocket Message" algorithm nor
> says it may not.
>
> ----
>
> 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.
>
> ----
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 26 Feb 2014 10:37:46 +0900

> close by itself, by polling bufferedAmount, and only call close()

The "queue" referred by some texts in the WebSocket API spec is also
underspecified. It doesn't say the queue is not used by close frame
sending. Chromium uses the same queue. There can be implementations that
allow a close frame overtake buffered data. Then, you're right.

> without a way to registered a callback.

The API should have some method to get notified of full/partial drain of
the buffer. Also, it's said to be an issue that there's no way to know how
much the upper limit of buffer size is on the UA in use.

> nor
> requests
> receiving

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 26 Feb 2014 04:49:57 -0800

Takeshi,

it's my impression that this whole thread has reached some kind of dead end.

There is one camp of people which would see "Plan D" (that is pure/raw tunneling of WS over HTTP2) as both sufficient and suitable.

"Plan D" can provide a "scalable transport for the WebSocket API", and can also be actually called "WebSocket tunneling", since it maintains the whole WS semantics.

"Plan D" also does not restrict RFC6455 design space (including any extensions) in any way.

And this, I _do_ care about: the integrity and design freedom of the WebSocket protocol.

So from a Chromium developers point of view, what is missing in "Plan D"?

FWIW, we are interested in developing a WS extension ("permessage-priority") that supports message priorization (and could also support multiple logical channels).

From a Chromium developers point of view: are you open to consider other options of reaching your goal: "scalable transport for the WebSocket API"?

/Tobias

Von: Takeshi Yoshino [mailto:[email-masked]]
Gesendet: Montag, 24. Februar 2014 23:36
An: Tobias Oberstein
Cc: Yutaka Hirano; Peter Thorson; Roberto Peon; [email-masked]
Betreff: Re: Straw poll: Do you miss interjectable WebSocket level control frame? (was: Re: [hybi] Discontinuation of mux ...)

On Wed, Feb 19, 2014 at 8:45 PM, Tobias Oberstein <[email-masked]<mailto:[email-masked]>> wrote:
I don't agree with that approach. I think HTTP2 should take WebSocket "as is", if it wants to act as a transport instead of attempting to redefine it. Or define it's own messaging (not bound by WS).

---

From: Ian Hickson <[email-masked]>
Date: Wed, 26 Feb 2014 17:35:10 +0000 (UTC)

On Wed, 26 Feb 2014, Takeshi Yoshino wrote:
> 
> 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.

If it doesn't allow it, then it's not allowed.

If you send a bunch of messages, then start the closing handshake, then 
the messages should all be sent. I don't think there's anything in either 
spec that would allow the handshake to jump ahead.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 27 Feb 2014 02:52:46 +0900

> If it doesn't allow it, then it's not allowed.

Yeah, it's kinda twist.

But also it's not strange that people wonder if close frame interjection
like this is ok or not. Actually, even ping/pong sending are not explicitly
allowed to be inserted between "Send a WebSocket Message" algorithm.

The only normative text talking about interjection are this one in
https://tools.ietf.org/html/rfc6455#section-5.5
"Control frames can be interjected in the middle of a fragmented message."
and this in https://tools.ietf.org/html/rfc6455#section-5.4
"Control frames (see Section 5.5) MAY be injected in the middle of a
fragmented message."

> spec that would allow the handshake to jump ahead.

It would be nice if you add some note to the API spec to say "queuing"
doesn't have any implication that the closing handshake can jump in in
response to Zhong's question above.

---

From: Ian Hickson <[email-masked]>
Date: Wed, 26 Feb 2014 17:58:17 +0000 (UTC)

On Thu, 27 Feb 2014, Takeshi Yoshino wrote:
> like this is ok or not. Actually, even ping/pong sending are not 
> explicitly allowed to be inserted between "Send a WebSocket Message" 
> algorithm.

If it's unclear, we should update the protocol spec to make it clear.

> > If you send a bunch of messages, then start the closing handshake, 
> > then the messages should all be sent. I don't think there's anything 
> > in either spec that would allow the handshake to jump ahead.
> 

Can you file a bug explaining specifically what needs clarifying at the 
API level? I'll get to it ASAP (I'm in the middle of an edit on focus 
navigation, so I can't fix it right now). http://whatwg.org/newbug

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 27 Feb 2014 03:08:44 +0900

> If it's unclear, we should update the protocol spec to make it clear.
I can't file a ticket.

Sal, could you file a ticket for this for update in the future?

> navigation, so I can't fix it right now). http://whatwg.org/newbug

Thanks. Filed.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24824

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 27 Feb 2014 04:47:20 +0900

On Wed, Feb 26, 2014 at 9:49 PM, Tobias Oberstein <
[email-masked]> wrote:

> There is one camp of people which would see "Plan D" (that is pure/raw
> tunneling of WS over HTTP2) as both sufficient and suitable.
>
>
>
> "Plan D" can provide a "scalable transport for the WebSocket API", and can
> also be actually called "WebSocket tunneling", since it maintains the whole
> WS semantics.
>
>
>

I basically agree with you for most of the points here, but cannot ignore
input from Roberto. I've been also struggling to adopt WebSocket for Google
infrastructure and facing various difficulties which includes additional
complexity for introducing new protocol. I'm not saying Google is the only
target, but we need to respect large scale loadbalancer developers'
perspective.

> FWIW, we are interested in developing a WS extension
> ("permessage-priority") that supports message priorization (and could also
> support multiple logical channels).
>
>
>
> From a Chromium developers point of view: are you open to consider other
> options of reaching your goal: "scalable transport for the WebSocket API"?
>

Yes. But sorry I haven't got a chance to read through your proposal yet.

>
>
> /Tobias
>
>
>
>
>
>
>
> *Von:* Takeshi Yoshino [mailto:[email-masked]]
> *Gesendet:* Montag, 24. Februar 2014 23:36
> *An:* Tobias Oberstein
> *Cc:* Yutaka Hirano; Peter Thorson; Roberto Peon; [email-masked]
> *Betreff:* Re: Straw poll: Do you miss interjectable WebSocket level
> control frame? (was: Re: [hybi] Discontinuation of mux ...)
>
>
>
> What Roberto and Martin are suggesting sounds like one to be categorized
> as "define it's own messaging". Some of Yutaka's plans, too. What's your

---

From: Peter Thorson <[email-masked]>
Date: Fri, 28 Feb 2014 10:16:57 -0600

To clarify here. This is a decision made that affects the W3C browser API only, correct? It does not imply that injecting a close frame into the outgoing message to cleanly cancel and exit is violating RFC6455?

---

From: Takeshi Yoshino <[email-masked]>
Date: Sat, 1 Mar 2014 03:00:32 +0900

On Sat, Mar 1, 2014 at 1:16 AM, Peter Thorson <[email-masked]> wrote:

> To clarify here. This is a decision made that affects the W3C browser API
> only, correct? It does not imply that injecting a close frame into the
> outgoing message to cleanly cancel and exit is violating RFC6455?
>

Right. Only Hixie expressed his thoughts and interpretation of the spec for
now. There should be more discussion for this.

---

From: Zhong Yu <[email-masked]>
Date: Fri, 28 Feb 2014 14:45:59 -0600

On Wed, Feb 26, 2014 at 11:35 AM, Ian Hickson <[email-masked]> wrote:
> the messages should all be sent.

I think this is a good choice for most use cases. But eventually
someone will need the feature of abort/cancel an outgoing message that
takes too long to transmit.

If write() is a blocking method, it makes sense that close() after
write() should flush the data at best effort. But here write() is a
non-blocking, async method, it's not intuitively clear what should
happen if close() is called when a write action is still ongoing.

Zhong Yu

> I don't think there's anything in either

---

From: Ian Hickson <[email-masked]>
Date: Fri, 28 Feb 2014 21:00:39 +0000 (UTC)

On Fri, 28 Feb 2014, Zhong Yu wrote:
> 
> I think this is a good choice for most use cases. But eventually someone 
> will need the feature of abort/cancel an outgoing message that takes too 
> long to transmit.

Once someone has a use case for this, we can study it and consider the 
right solution.

> happen if close() is called when a write action is still ongoing.

In the Web Socket API, WebSocket.send() and WebSocket.close() are both 
specced as atomic. The fact that buffering has to happen is an 
implementation detail (albeit one exposed in the bufferedAmount 
attribute). The protocol spec could provide more detailed hooks to control 
this, of course. But I don't think the specs are unclear.