Re: 6455 Websockets and the relationship to HTTP

Loïc Hoguin <> Fri, 02 December 2016 09:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56127129BB4 for <>; Fri, 2 Dec 2016 01:39:27 -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 6K2teYNmJVHF for <>; Fri, 2 Dec 2016 01:39:25 -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 19006129BC1 for <>; Fri, 2 Dec 2016 01:39:24 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cCkFz-0006Q6-5H for; Fri, 02 Dec 2016 09:35:51 +0000
Resent-Date: Fri, 02 Dec 2016 09:35:51 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cCkFl-0006PB-LQ for; Fri, 02 Dec 2016 09:35:37 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1cCkFV-00033I-02 for; Fri, 02 Dec 2016 09:35:22 +0000
Received: from [] ([]) by (mreue103 []) with ESMTPSA (Nemesis) id 0Lxuke-1cilg72BK0-015LNJ; Fri, 02 Dec 2016 10:34:51 +0100
To: Patrick McManus <>, HTTP Working Group <>
References: <>
From: Loïc Hoguin <>
Organization: Nine Nines
Message-ID: <>
Date: Fri, 02 Dec 2016 10:34:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:ZMdQZ/82TkJ55nHoMxVSGOPujrXn/dGJwDesMooJ+VD/wztD95i TcyH4udmgTU1nbCB7lVzE9a1C3CX00xHfiCm4Q5Ai+R1tz8rQxu0rTzdjLPrIt6Vymr7rV4 1MKjC5afCzH16KdNqF6coL3QXSP0u+ZjxcPQOa2a+qwSbAES3UktDgnG0pAp9joZ9KGWv+A dpTiFJ/HUqot0Pc3v3b+g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:eKrmk0l9xtY=:zP88bQ9RbhEP/lZx5hXNL0 zhdKMhcaCA4rMNBUZJmO1YYUC4+smYJqKy1ArKMDu/ebKDlUF1Ej11OT7BO2URnBsKMP6O6vH oc3VQrK/f/IJg+clA72NUoBJ2U/VUq/oPuRZPMdgYw4nfrxHd/wkhdgnalF+ZSE5Gk9usmp0E TRR1zboOHAS1OzTOpZs3t5m1Wutd09HBOYvgmpnfBvEECmokpqobvm6fnF5Loxq2tqOQEJODW gCfNQx8g7x6jIZjJK7YdzULEAe6voFKKRyH4uSdhuN3HE+tbrW4u3W0tOLSSoj1KbT9hJhjUD 5cCeHyns6jHc7c3rTjG25n99sWJeKhMJyjA39dHMs8UfEqAy8cWmBUAeK8nbuenFdD32i1d7k vlp+9n4MpZxQ4IoofuoXRaCMp3Yjp1gXItj30jjIRsjwb3sk6LUrTXwq5ecea0tH3ercnYomu JUnyCZkFu8v2DwHjxNgGuOQjH0tQdUp6yNN25YXVVoJs9CKW9PQNENoAT0GdLTL0GnjfMuJeP 7ovvwuuLTx+tqqGXNtSxAeXQ5noTOs4vkgA5VHhhGlHAGbXLN2fr3RNNlLpCxInSjXnMRhW5m xbwfHjBvBuvgkYmASae7rhZ4MUw0cVesuJQeOkCkSo8io9TCHQWNvj0fYgaMi6tMYbjCjV2WO qykgBXo5uwdztkgJePU3QwqYkEVC6lL6hCjahVQU/Rjr7DUIZMSVRE+f3ljB7SpsheljNBOfw 1V0PXShZioOXLdNI
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cCkFV-00033I-02 23e3220f2b56f25b1f381fe1b2d9e7f2
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/33087
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 12/01/2016 04:48 PM, Patrick McManus wrote:
> Here's what I think I'm hearing, but there are so many messages that are
> done in the weeds of the solution space I don't want to lose track of
> the problems being solved - I think this list might help in any
> chartering discussion:
> * in a practical sense there is no mux and when you have mux you need
> priority and flow control. h2 solves this.
> * operational overhead of maintaining/admin h1 just to boostrap to
> websockets.
> * latency of a new h1 connection just to bootstrap to websockets
> * operational overhead of separate conns for http and ws
> is there more? some data on this stuff would be good. Is this really
> mostly about mux?

Multiplexing is interesting but probably a special case that few people 
require, although I can imagine people using it "because they can".

What is more interesting is the flow control (regardless of mux). While 
you can implement a backpressure mechanism on the server by not reading 
from the socket, the flow control allows you to prevent the client or 
the server from sending anything at all, saving resources for other 
connections. This would be a pretty good improvement for RabbitMQ's 
STOMP/MQTT over Websocket, for example.

Ultimately it's just optimizations I think.

WiSH is very interesting because it provides this at minimal costs: same 
framing as Websocket (therefore, same code), existing connection 
handling from H2, HTTP semantics for request routing, methods, content 
negotiation. It could even be used over HTTP/1 should one wish to do so.

I don't think WiSH requires any updates to HTTP to work.

I would be wary of solutions that add new H2 frames, as they require yet 
another implementation. WiSH would work as long as the HTTP semantics 
don't change, and these are shared between HTTP/1 and H2. It's a more 
future proof solution IMO.

Loïc Hoguin