Re: 6455 Websockets and the relationship to HTTP

Willy Tarreau <> Fri, 02 December 2016 06:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6D831295A9 for <>; Thu, 1 Dec 2016 22:40:13 -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 MDXAUhyOPrdk for <>; Thu, 1 Dec 2016 22:40:11 -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 81BA012949E for <>; Thu, 1 Dec 2016 22:40:11 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cChRx-0003G6-Ts for; Fri, 02 Dec 2016 06:36:01 +0000
Resent-Date: Fri, 02 Dec 2016 06:36:01 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cChRn-0003ET-NP for; Fri, 02 Dec 2016 06:35:51 +0000
Received: from ([] by with esmtp (Exim 4.84_2) (envelope-from <>) id 1cChRg-0000EA-LW for; Fri, 02 Dec 2016 06:35:46 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id uB26ZD60018010; Fri, 2 Dec 2016 07:35:13 +0100
Date: Fri, 02 Dec 2016 07:35:13 +0100
From: Willy Tarreau <>
To: Patrick McManus <>
Cc: Mark Nottingham <>, Kazuho Oku <>, Martin Thomson <>, HTTP Working Group <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.0 (2016-04-01)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.571, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cChRg-0000EA-LW 507ffa6ba90865786ed4b067ce35345a
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/33086
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, Dec 01, 2016 at 08:34:26PM -0500, Patrick McManus wrote:
> On Thu, Dec 1, 2016 at 8:00 PM, Mark Nottingham <> wrote:
> >
> > That's another way to do it too, provided the latency hit isn't critical.
> > Since you've already got the H2 connection open in the typical case for WS,
> > I think that'd work well, but I could be unaware of some use case that
> > requires WS on the first RT.
> Doing it with settings on alpn=h2 is a little tricky.. if you need to make
> a new connection (e.g. you have none open) for wss do you do it with
> alpn=h2 and hope for the setting and then fall back to a new connection
> with h1 and upgrade if it doesn't work? That's a new pile of round trips
> for legacy servers. otoh doing it via alpn makes it easy by offering
> wsoverh2 and h1 in the handshake.. it also makes it easy for the h1 server
> to use alt-svc to advertise a better version elsewhere as we see quic do.

But I think that it's important to focus on the future, ie assume support by
default, and lose a round trip in case the assumption was bad. When properly
done, it adds the round trips only for old servers, giving incentive for
them to upgrade, without breaking compatibility.

Ideally we would need to use new frame types to create streams of type WS,
which would be rejected by an RST_STREAM by implementations not supporting

Another possibility would be to define H2.1 which would support extra
protocols by default unless the server explicitly rejects them. That would
be immediately advertised by ALPN and servers would progressively move
towards this one.