Re: 6455 Websockets and the relationship to HTTP

Andy Green <andy@warmcat.com> Fri, 02 December 2016 19:58 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF16126D74 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 2 Dec 2016 11:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.797
X-Spam-Level:
X-Spam-Status: No, score=-9.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCyVZfJMJdhn for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 2 Dec 2016 11:58:28 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4D9124281 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 2 Dec 2016 11:58:28 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cCtvf-0005KP-9G for ietf-http-wg-dist@listhub.w3.org; Fri, 02 Dec 2016 19:55:31 +0000
Resent-Date: Fri, 02 Dec 2016 19:55:31 +0000
Resent-Message-Id: <E1cCtvf-0005KP-9G@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <andy@warmcat.com>) id 1cCtvY-0005Ix-4v for ietf-http-wg@listhub.w3.org; Fri, 02 Dec 2016 19:55:24 +0000
Received: from mail.warmcat.com ([163.172.24.82]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <andy@warmcat.com>) id 1cCtvR-00046Q-14 for ietf-http-wg@w3.org; Fri, 02 Dec 2016 19:55:18 +0000
In-Reply-To: <7d0180d5-b3fa-dc7f-e211-a6b9ae0d826c@gmail.com>
References: <CAOdDvNqk7W_oNWUismMb-ZuhvdboZNDQ0YV2BLsbka-FGC-7oA@mail.gmail.com> <39F32B28-7116-478A-B02A-E8310EA6E189@mnot.net> <CABkgnnVZeLQGES5Dige8u+ukSgqSfJNKiCuL=oK3gQnAb_3LNw@mail.gmail.com> <CANatvzwoUYaC_YPTTF6fdwN5aOiwrttyH9Xj7xYVR1i1DZ27bA@mail.gmail.com> <037D2D57-7423-4375-9FEC-50B3106F42ED@mnot.net> <CANatvzx=mOQ3kE-vnvwNvD2w26+RNTueHgu7BhHLnJixn0vRcw@mail.gmail.com> <9e6f1a46-a782-a688-5b16-836d28032823@treenet.co.nz> <1480646012.4219.21.camel@warmcat.com> <CAOdDvNqShPUdu6zt-dPDpXm31eP2xX_dahrTr8JEbOOGQFFNSw@mail.gmail.com> <220b575c-a953-a8fe-1591-00d1e676b201@gmail.com> <CAOdDvNpdxHWj97S=A+Xtf5k3aWfSWg6AStxji4PKemw=xnH_XQ@mail.gmail.com> <7d0180d5-b3fa-dc7f-e211-a6b9ae0d826c@gmail.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Andy Green <andy@warmcat.com>
Date: Sat, 03 Dec 2016 03:54:47 +0800
To: Jacob Champion <champion.p@gmail.com>, Patrick McManus <mcmanus@ducksong.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <A5761229-B012-496C-8AFD-C9FBC85DB4FC@warmcat.com>
Received-SPF: pass client-ip=163.172.24.82; envelope-from=andy@warmcat.com; helo=mail.warmcat.com
X-W3C-Hub-Spam-Status: No, score=-5.6
X-W3C-Hub-Spam-Report: AWL=1.202, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cCtvR-00046Q-14 108d2b1cc9e1e5eb881d2c9989477835
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <http://www.w3.org/mid/A5761229-B012-496C-8AFD-C9FBC85DB4FC@warmcat.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33097
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>


On December 3, 2016 2:36:56 AM GMT+08:00, Jacob Champion <champion.p@gmail.com> wrote:
>On 12/02/2016 10:02 AM, Patrick McManus wrote:
>>
>> On Fri, Dec 2, 2016 at 12:52 PM, Jacob Champion <champion.p@gmail.com
>> <mailto:champion.p@gmail.com>> wrote:
>>
>>     so that existing clients of WS subprotocol
>>
>> you had me at subprotocol.
>>
>> which one(s)? Pointers to definitions? It would be interesting to see
>> how well that mechanism took off - mostly I've seen it used for
>versioning.
>
>If you mean the registered list:
>
>     https://www.iana.org/assignments/websocket/websocket.xml
>
>It's grown a bit since last I looked. Twenty-five or so?
>
>> but secondarily, sub-protocol negotiation is part of the js api so I
>> probably need a little clarification about what you have in mind as
>the
>> gap you objected to wrt subprotocol. Thanks.
>
>Right, the negotiation itself wasn't so much what my fear was about. 
>I'll need to dig the specs out again, but the two (admittedly minor) 
>gaps that I remember right now are application-data pings and 
>frame-by-frame message streaming. There might be others.

h2 has a PING concept at connection (not stream) level... differences are fixed 8-byte payload instead of up to 126 bytes, and no requirement in h2 that the PONG payload is identical.

I've only ever seen ws PING used as a 'communication still alive' probe, but actually h2 connectivity PING and a PING in the muxed ws2 stream would be semantically different aside from the actual differences.  A PING in the stream can also tell you the ws2 server is still alive, not just the connection to the h2 endpoint.  Ws PING does tell you the ws peer is also up.

So you're probably right ws2 explicit PING is also needed.

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

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.

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; they used their protocol if they had such things.  It's used purely a probe in my experience.

But I think you don't need to make that kind of reach... the ability to confirm the peer who understands ws2 is still up for that stream, like ws PING does, instead of just the h2 endpoint is enough to also require explicit ws2 PINGs as you suggested.

But that's all, over the JS API...

-Andy

>For the record, I'm not currently aware of a *specific* subprotocol
>that 
>would break using only the WS API subset. That would be better answered
>
>by the HyBi experts, I think.

>--Jacob