Re: 6455 Websockets and the relationship to HTTP

[Van Catha <[e-mail]>]

I do not see the need for Ping, Pong or Close ws frames. The h2/quic
transport layer handles this. If you want to measure latency then send your
own pings/pongs, do not bake it into the protocol.  There is no need for
this, and if there is, please present a compelling reason.

The clientside API should not change, but it should definitely be extended
OR more functionality should be added to browsers, like the ability to
compress data from inside JS land.



On Fri, Dec 2, 2016 at 4:41 PM, Jacob Champion <[e-mail]> wrote:

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