Re: 6455 Websockets and the relationship to HTTP

Andy Green <> Fri, 02 December 2016 19:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AF16126D74 for <>; Fri, 2 Dec 2016 11:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.797
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fCyVZfJMJdhn for <>; Fri, 2 Dec 2016 11:58:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB4D9124281 for <>; Fri, 2 Dec 2016 11:58:28 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cCtvf-0005KP-9G for; Fri, 02 Dec 2016 19:55:31 +0000
Resent-Date: Fri, 02 Dec 2016 19:55:31 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cCtvY-0005Ix-4v for; Fri, 02 Dec 2016 19:55:24 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1cCtvR-00046Q-14 for; Fri, 02 Dec 2016 19:55:18 +0000
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Andy Green <>
Date: Sat, 03 Dec 2016 03:54:47 +0800
To: Jacob Champion <>, Patrick McManus <>
CC: HTTP Working Group <>
Message-ID: <>
Received-SPF: pass client-ip=;;
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: 1cCtvR-00046Q-14 108d2b1cc9e1e5eb881d2c9989477835
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/33097
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On December 3, 2016 2:36:56 AM GMT+08:00, Jacob Champion <> wrote:
>On 12/02/2016 10:02 AM, Patrick McManus wrote:
>> On Fri, Dec 2, 2016 at 12:52 PM, Jacob Champion <
>> <>> 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
>If you mean the registered list:
>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
>> 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

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


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