Re: 6455 Websockets and the relationship to HTTP

[Jacob Champion <[e-mail]>]

On 12/02/2016 12:58 PM, Andy Green wrote:
> On December 3, 2016 4:18:06 AM GMT+08:00, Jacob Champion <[e-mail]> wrote:
>> My point is just that this ability to multiplex control frames inside
>> of
>> in-flight messages is not something that is explicitly exposed by the
>> JS
>> API, but it may be something that a (non-browser) client requires for
>> proper operation. I think WS/2 should still support it, regardless of
>> whether or not a JS client can make use of it.
>
> OK.  Although the only relevant control frames are PING / PONG.

CLOSE too, plus any control frames added to the protocol between now and 
the release of WS/2.

> And if a client wants to send control frames inside a huge message, that client must have explicitly fragmented the message already.
>
> The general idea is just map ws2 payload frames direct to h2 framing... refragmenting them to fit.  In that way, 'supporting' ws1 63-bit frame lengths compatibly doesn't require 63-bit frame lengths in ws2 because ws always allows refragmentation of frames.

Agreed.

> So it only creates more fragmentation / opportunities to insert control frames, so no problem.
>
>> Let me step back: when you say that your goal is to "provide a
>> transport
>> for JS WS API on h2", my fear is that this could lead to a situation
>> where semantics that are part of WS/1 are removed from WS/2 for no
>> reason other than "Javascript clients don't need it, so no one else
>> does
>> either." I would like to avoid that.
>
> What I meant by that is ws1 wire protocol can go out the window completely.  The job is not wrap ws1 verbatim in h2 frames, keep ws1 negotiation headers, masking, etc.  It can be radically recast to align with h2 while following the JS API, and fully exploit new possibilities like roundtrip elimination.
>
> I agree it should make some effort to not break non JS / browser uses.  But it's no coincidence there are only a tiny number of corner cases about that -- ws1 was itself designed to implement a transport for the ws JS API.

It sounds like we're on the same page, as long as the eventual 
solution's authors understand those corner cases, and that the 
functionality provided by WebSocket is (to a minor extent) a superset of 
what's provided by the JS API. In particular, I agree that we don't 
necessarily need to be bound by the current wire format, or the same 
HTTP-buster security features, as WS/1.

--Jacob