Re: 6455 Websockets and the relationship to HTTP

Mark Nottingham <> Fri, 02 December 2016 00:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6ED3B129A08 for <>; Thu, 1 Dec 2016 16:13:58 -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 wSpXDwyzTrhm for <>; Thu, 1 Dec 2016 16:13:56 -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 40A30129489 for <>; Thu, 1 Dec 2016 16:13:56 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cCbQj-0003tR-PC for; Fri, 02 Dec 2016 00:10:21 +0000
Resent-Date: Fri, 02 Dec 2016 00:10:21 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cCbQc-0003rY-R6 for; Fri, 02 Dec 2016 00:10:14 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1cCbQW-0005Qy-5C for; Fri, 02 Dec 2016 00:10:09 +0000
Received: from [] (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7AD4F22E256; Thu, 1 Dec 2016 19:09:44 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Fri, 02 Dec 2016 11:09:41 +1100
Cc: HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Patrick McManus <>
X-Mailer: Apple Mail (2.3251)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.1
X-W3C-Hub-Spam-Report: AWL=1.546, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1cCbQW-0005Qy-5C 8ad31e225bbe5e17e65e68f355455f7d
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/33074
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 2 Dec. 2016, at 2:48 am, Patrick McManus <> wrote:
> Hi All.
> The continued websockets discussion is interesting to me - its clear the number of interested parties is small but significant (e.g. almost nobody in the room in Seoul had read the presented draft, but a diverse number of participants are making related technical contributions on the list.). The general advice remains in effect - 6455 wasn't done in HTTPbis so its best to seek another venue (a new wg, or perhaps dispatch help) for an update - but when it comes to its interaction with HTTP that's on topic for this WG and there probably is some expertise. So I don't mind the conversation continuing as long as a parallel effort to find a home for actually adopting the work is made.
> I would like to use this thread to better understand, for my own edification, what the problem being addressed here is and how big of a problem it is in practice. Its not controversial to say that 6455 has warts, and given the toolbox we have now it would be done differently - but what in terms of operations would be improved by an update to a h2 world? Would that be a different set of answers for a quic world?
> 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?
> I can see where the introduction of quic makes this gap even bigger.. with its lower latency and potential to deploy more modern transport features. It would be great to be more crisp on this - I have read and its still not clear to me what the driving concern is.

In particular, my recollection of the outcome of the discussion of WS in H2 was that a new SETTING or a new ALPN token could be used to indicate that a connection supports both H2 and WS. If there's a problem with doing so, that would be good to talk about as well. Especially considering QUIC.


Mark Nottingham