W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: 6455 Websockets and the relationship to HTTP

From: Jacob Champion <champion.p@gmail.com>
Date: Fri, 2 Dec 2016 12:18:06 -0800
To: Andy Green <andy@warmcat.com>, Patrick McManus <mcmanus@ducksong.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <af3a3783-4cf6-6e30-4d3c-c7e856894f9f@gmail.com>
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.

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.

> 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:18:49 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 December 2016 20:18:51 UTC