Re: 6455 Websockets and the relationship to HTTP

Andy Green <> Fri, 02 December 2016 00:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23A70129A15 for <>; Thu, 1 Dec 2016 16:53:37 -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 xgzRgWsedG-0 for <>; Thu, 1 Dec 2016 16:53:34 -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 39777129A1A for <>; Thu, 1 Dec 2016 16:53:33 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cCc38-0004CI-F8 for; Fri, 02 Dec 2016 00:50:02 +0000
Resent-Date: Fri, 02 Dec 2016 00:50:02 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cCc31-0003p4-Hl for; Fri, 02 Dec 2016 00:49:55 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1cCc2u-0006qG-J0 for; Fri, 02 Dec 2016 00:49:50 +0000
In-Reply-To: <>
References: <>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Andy Green <>
Date: Fri, 02 Dec 2016 08:49:22 +0800
To: Patrick McManus <>, HTTP Working Group <>
Message-ID: <>
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.9
X-W3C-Hub-Spam-Report: AWL=-0.101, 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: 1cCc2u-0006qG-J0 77180044abf92b76062302dd7479bd90
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/33076
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On December 1, 2016 11:48:20 PM GMT+08:00, Patrick McManus <> wrote:
>Hi All.
>The continued websockets discussion is interesting to me - its clear
>number of interested parties is small but significant (e.g. almost
>in the room in Seoul had read the presented draft, but a diverse number
>participants are making related technical contributions on the list.).
>general advice remains in effect - 6455 wasn't done in HTTPbis so its
>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
>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 -
>what in terms of operations would be improved by an update to a h2
>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
>done in the weeds of the solution space I don't want to lose track of
>problems being solved - I think this list might help in any chartering
>* 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
>* latency of a new h1 connection just to bootstrap to websockets
>* operational overhead of separate conns for http and ws

Yes these are correct, but they are more optimization opportunities.

>is there more? some data on this stuff would be good. Is this really
>about mux?

For people using ws on http/1, it seems quite strange it's more or less alone in terms of http/1 features widely implemented in browsers NOT provided a way to work on h2.

>From the point of view of this group it's "obviously" a different standard and the focus is, and has been, on moving discussion to someone else's lawn.  But from browser user perspective it's all mixed in and wants to be handled by the same server and protocol, from that perspective there is an impedance mismatch with the feeling here, and it looks to them like either ws is being effectively deprecated, or h2 guys dropped the ball and 'missed it out'.

I understand "that's not how it is" from the perspective of the process of the people here.  But for people not involved that's not an unreasonable take on the situation they will find trying to use ws on h2 right now.

So this should be solved, I think...


>I can see where the introduction of quic makes this gap even bigger..
>its lower latency and potential to deploy more modern transport
>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.