Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

Takeshi Yoshino <> Fri, 10 November 2017 16:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C6561205D3 for <>; Fri, 10 Nov 2017 08:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rNuMl9KITbbg for <>; Fri, 10 Nov 2017 08:51:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B93A12741D for <>; Fri, 10 Nov 2017 08:51:27 -0800 (PST)
Received: by with SMTP id e19so7730957qte.8 for <>; Fri, 10 Nov 2017 08:51:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Thxi64T4JlrOLKMQmH9lbtr0doZ0LpXpsyH524R5kXk=; b=evCUqVIuz63vsRO+mXawRIHr7gI4OdOPxu8PKID+9q5FJFCeLdMpuasYhkb5cbtJ42 oXjsaL1Nzq+EZKkPVDcb4XZvBmIss3vlkpCfJAQ8rWyqs01O8rrizR4/dwYTLZzfOKwe 0HSNTfuZ/yW2iydpW+HYP2BhNG9pjWkZInziQg2ntrELIIDvICSRPErc/yAoDrxDPBoJ uA0BjAUvBL3OYxGskeuTrnNEEGiiLflcXcQhDOnfdklIk0efjItMOo7GLlbzTrl9AJX7 zWy7+7oDy1u8G9z325cgoPb5nI5ez4oK0LIH3xdCI70GbSGj1hYJTZBtetQ8st0G8wuF DUUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Thxi64T4JlrOLKMQmH9lbtr0doZ0LpXpsyH524R5kXk=; b=UqdRma8E5D4Jk58SfG6MKT/vvLkTLw92s73l+mZ9Evje62xwbqzMK3LgBNdu9I35/o g/yApiXUijiZjZNt9pMjTEdowylZ7FKJ5FMlhmTbF7h7H8vXFJrzjekPWH7IFNiaQLac b/tlJqe+NtIFULz1nxSdirbVySyo7ZVgEVjXkksUuRjDjxl0CqqXLQRLAJecEf4Z+YCN qv59Of1Pej3hifN+1BO1dgdaQjzQMrlgtb2LO9BrAhSj3r+yPPIwI6twWQCAnofpCTRs M95PPxgPPExM2UOa079lg43pjJU0bk2WDSkBe5zdnNBm64/s3N24vMXeHty06+NWFx6r tCYw==
X-Gm-Message-State: AJaThX610s2VeKzQ5kORqEkABeZkNRaLmPwJuhDw0TPWz/Rm7zJVVxuN hu8HZ1zTp3zQixc3Pw2rScCpXza1utz2YYBnmI6WbA==
X-Google-Smtp-Source: AGs4zMYBGh15nctgvZoNV1X2hSJTaZ1iIWWpOGwRmXpPoLoAr13LPMZ4iLgxkL9J2J8w/sYIve06d0qXWlf1KvcnG0Q=
X-Received: by with SMTP id t51mr1591528qtc.90.1510332686390; Fri, 10 Nov 2017 08:51:26 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 10 Nov 2017 08:51:05 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Takeshi Yoshino <>
Date: Sat, 11 Nov 2017 01:51:05 +0900
Message-ID: <>
To: Kazuho Oku <>
Cc: Kari Hurtta <>, hybi <>, Patrick McManus <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="001a11420b0a44784a055da3bb49"
Archived-At: <>
Subject: Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Nov 2017 16:51:30 -0000

On Fri, Nov 10, 2017 at 4:05 PM, Kazuho Oku <> wrote:

> 2017-11-10 15:14 GMT+09:00 Kari Hurtta <>:
> > Then that ":upgrade" works as explicit tunneling mechanism, IF you can
> trust
> > that response is treated as mailformed (stream error of type
> > when proxies/frameworks does not subscribe that tunneling mechanism.
> >
> > Can you trust that?
> Note that we would be doing negotiation beforehand using a SETTINGS
> parameter. Otherwise, a client cannot send a request with `:upgrade:`
> pseudo header.
> I believe that a successful negotiation would be sufficient to
> guarantee that the `:upgrade:` response header will be recognized as a
> signal (or a 101 status code as a signal).

Agreed with Kazuho about this point.

Depending on such detection of a spec violation is interesting, but I think
we shouldn't. It's fragile. We're already clearing the path between the
endpoints by the forwarding of the SETTINGS. That should be enough, yes.

I'd rather suggest that we don't violate RFC 7540. As we'll be using a
pseudo header, we anyway need special logic to generate/parse it. So, it
doesn't matter so much whether the name is "upgrade" or not. We could e.g.
use ":upgrade", and ":upgrade-response" in each direction respectively.

I listed a few more points below that I think we should get consensus. But
basically, I like the direction (use of HEADERS, signaling by SETTINGS).


I remember that we had some discussion about this kind of usage of the
SETTINGS frame mechanism with H2 connection bundling/un-bundling proxies on
the way, when we were discussing Yutaka's WS/H2 I-D
<> 3
y ago.

Suppose that we have a reverse proxy that has a single H2 connection with a
browser which is unbundled by the proxy to different target backends (still
H2 but with fewer streams) where some backends can handle tunneling, but
some cannot. The proxy needs to either:
- forward the SETTINGS to the browser to allow it to use tunneling, but
convert tunneling requests to the tunneling/H2 non-capable backends to one
over H1
- don't forward the SETTINGS as not all backends are capable of it

As SETTINGS is about hop-by-hop characteristics, we need to consolidate the
bit as above at bundling points. I think this is fine and we don't want to
introduce any complicated mechanism to perform e2e negotiation. Do you all
agree on this?


In Yutaka's I-D, we tried to allow speculatively initiating a WebSocket
over H2 without waiting for capability announcement by the server. In
Patrick's proposal, we instead wait for the SETTINGS frame before
initiating a WebSocket.

How and when should a browser determine whether a certain H2 connection is
tunneling capable or not?

What's in my mind is:

- When there's no connection at all,
  - ws: RFC 6455 connection attempt is made on TCP but with the
HTTP2-Settings header in addition to the standard RFC 6455 headers, which
might get upgraded to WS/H2 (indicated by e.g. an additional header, or a
special Upgrade value "websocket-h2c") or just proceed as RFC 6455
  - wss: Use ALPN? See
- When there's ongoing H2 connection establishing, the browser waits until
the initial SETTINGS is received following the preface. If there
isn't ENABLE_CONNECT_PROTOCOL, the browser should use WS/TCP. Otherwise, it
should use WS/H2.
- When there's existing H2 connection established, if there wasn't
ENABLE_CONNECT_PROTOCOL in the initial SETTINGS from the server, use
WS/TCP, and WS/H2 otherwise.

Initially, I thought it might be fine to assume that there's existing H2
when WS attempt is made, but it's not always true, I guess.


Is it ok that we cannot announce tunneling capability for each protocol
separately? draft-hirano-httpbis-websocket-over-http2-01 allocated a
dedicated SETTINGS identifier for WebSockets
while draft-hirano-httpbis-websocket-over-http2-00 let each bit indicate
capability for each protocol.

In Patrick's proposal, currently we just determine tunneling yes/no and
then everything beyond is upper layer protocol's work.

I think this is fine if this tunneling is made completely independent from
the upper layer protocol.