Re: 6455 Websockets and the relationship to HTTP

Andy Green <> Fri, 02 December 2016 21:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C03B0120725 for <>; Fri, 2 Dec 2016 13:01:59 -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 PSGs8FGihWnV for <>; Fri, 2 Dec 2016 13:01:57 -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 3AAC71293EB for <>; Fri, 2 Dec 2016 13:01:56 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cCuv7-00043K-JZ for; Fri, 02 Dec 2016 20:59:01 +0000
Resent-Date: Fri, 02 Dec 2016 20:59:01 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cCuv0-00042M-CR for; Fri, 02 Dec 2016 20:58:54 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1cCuus-0007LB-FK for; Fri, 02 Dec 2016 20:58:49 +0000
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Andy Green <>
Date: Sat, 03 Dec 2016 04:58:16 +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.8
X-W3C-Hub-Spam-Report: AWL=0.961, 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: 1cCuus-0007LB-FK be6fb225305d6480705df09d337a53a7
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/33099
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On December 3, 2016 4:18:06 AM GMT+08:00, Jacob Champion <> wrote:
>On 12/02/2016 11:54 AM, Andy Green wrote:
>> On December 3, 2016 2:36:56 AM GMT+08:00, Jacob Champion
><> wrote:
>>> (Since frame boundaries don't have *semantic* meaning in WS, the
>>> 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
>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
>in-flight messages is not something that is explicitly exposed by the
>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
>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
>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.


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