Re: 6455 Websockets and the relationship to HTTP

Andy Green <> Fri, 02 December 2016 03:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97622129A86 for <>; Thu, 1 Dec 2016 19:48:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.687
X-Spam-Status: No, score=-9.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DjWpWsBMfNeU for <>; Thu, 1 Dec 2016 19:48: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 6B6E1129A84 for <>; Thu, 1 Dec 2016 19:48:57 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cCemJ-0006lt-7X for; Fri, 02 Dec 2016 03:44:51 +0000
Resent-Date: Fri, 02 Dec 2016 03:44:51 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cCemB-0006kL-1c for; Fri, 02 Dec 2016 03:44:43 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1cCem4-0001Pi-DG for; Fri, 02 Dec 2016 03:44:37 +0000
DKIM-Filter: OpenDKIM Filter v2.10.3 3AB8FA1932
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1480650235; bh=63kBgqKQvQ9birAROTm6KQLdTghaqSXi2AmiCOGOWQw=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=J98VBjURvhJ1NCgvCvqDF6ZkFNkRJBpMwvtWVD9hKEpq0ng1yudKdOjBDkKqYcMCO UHYkypZtnXbQ4l8z4anZPhNkKus+zOy4gFEXNB4dP4PN8NQ4br50cQJzSQUgIKGZ2s 9/TkFCo+00xujCgoMAwlpvmPFXbVuxasZusK7pqU=
Message-ID: <>
From: Andy Green <>
To: Patrick McManus <>
Cc: Amos Jeffries <>, HTTP Working Group <>
Date: Fri, 02 Dec 2016 11:43:54 +0800
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.8
X-W3C-Hub-Spam-Report: AWL=-0.156, BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cCem4-0001Pi-DG 2f2e5727ea73d48243dd62bb49608424
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/33085
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, 2016-12-01 at 22:14 -0500, Patrick McManus wrote:
> On Thu, Dec 1, 2016 at 9:33 PM, Andy Green <> wrote:
> > The actual game here is "provide a transport for JS WS API on
> > h2".  It
> indeed - but what I'm trying to get to the root of in this thread is
> what motivates that. If the game is to get it into somebody's
> charter. that is going to need to be crisp. So far I've really only
> heard 2 strong motivators (along with a few complementary smaller
> ones)

Charters and such are about the politics of implementing it.  If it
doesn't get implemented, or maybe not implemented until more h2 rollout
amongst the Great Unwashed makes them turn up here asking the same
thing over and over, life will go on.

> 1] it is inherently a problem that 6455 can only be done on h1
> because it is left behind the h2 curve. To be honest, this is
> generally stated as a given but it isn't obviously true to me. I 

It's consistently been the case trying to discuss it here, but it's
still surprising to me.  One major browser feature is orphaned as it is
from h2.

> haven't heard this fleshed out very convincingly - I tried to give
> some seeds to help build that argument in the first message of this
> thread.. but to my mind there hasn't been a convincing case made yet
> that this is a problem (which isn't to say I think the case can't be
> made).
> 2] ws needs mux (and priority and flow control that go with it)  and
> h2 has already solved that thorny problem. I buy this if ws needs
> mux. I supported mux with Roberto in the hybi days and the wg decided
> against doing it in the base version as part of 6455. This seems to
> be a stronger argument  But has the lack of mux been a problem in
> practice for ws? anecdotes or data to support that?

Maybe I'm crazy but although these are advantageous, they are just
optimizations to me.

The basic problem is you can't deploy an h2 server that also does ws,
even in a not very efficient way.  This seems like something failed
somewhere, and one way or another should be enabled.

^--- that's all the "convincing" I plan to do.


> -P