Re: 6455 Websockets and the relationship to HTTP

On December 3, 2016 4:18:06 AM GMT+08:00, Jacob Champion <champion.p@gmail.com> wrote:
>On 12/02/2016 11:54 AM, Andy Green wrote:
>> On December 3, 2016 2:36:56 AM GMT+08:00, Jacob Champion
><champion.p@gmail.com> wrote:
>>> (Since frame boundaries don't have *semantic* meaning in WS, the
>major
>>> thing to keep for WS/2 is the ability to send control frames in the
>>> middle of a very large message, which IIUC the WS API does not
>>> currently
>>
>> Nah... if it's sharing an h2 connection, he's just one muxed stream. 
>And ws specifies any intermediary may refragment ws frames anyway. 
>Individual ws1 frames have no guarantee of making it to the peer
>atomically.
>
>Correct. That's what I meant by "frame boundaries don't have semantic 
>meaning"; sorry if that was unclear.
>
>> Of course ws (see RFC6455 5.4) explicitly "allows" "send[ing] control
>frames in the middle of a very large message"... a ws message comprises
>any number of frames of any legal length.  Inbetween the message
>fragment frames you may send control frames.
>
>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.  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.

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.

-Andy

>> So that one is just wrong I think.
>>
>>> allow. As for pings, the data reflected by the server could allow
>>> clients to perform rudimentary latency monitoring or something else
>>> clever at the application level, perhaps for clock
>synchronization...?)
>>
>> I never saw ws PING data like that
>
>I have. So... there's that. :D In my particular case, it didn't make it
>
>into production (as far as I know), but I've *seen* it.
>
>--Jacob

Received on Friday, 2 December 2016 20:58:54 UTC