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

Kari Hurtta <> Fri, 10 November 2017 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED19812EC88 for <>; Fri, 10 Nov 2017 09:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mBi0uklAlZ3C for <>; Fri, 10 Nov 2017 09:52:04 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDEB612EC79 for <>; Fri, 10 Nov 2017 09:52:03 -0800 (PST)
Received: from ( []) (envelope-from by (8.13.8/8.13.8/smtpgate-20161014/smtpVgate) with ESMTP id vAAHpr1P014050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Nov 2017 19:51:53 +0200
Received: from by with ESMTP id vAAHprT4001681 ; Fri, 10 Nov 2017 19:51:53 +0200
Received: from ([]) by with ESMTP id vAAHpr9B031732 ; Fri, 10 Nov 2017 19:51:53 +0200
Received: by id vAAHpqHC031731; Fri, 10 Nov 2017 19:51:52 +0200
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <>
To: Takeshi Yoshino <>
Date: Fri, 10 Nov 2017 19:51:52 +0200
From: Kari Hurtta <>
CC: Kazuho Oku <>, Kari Hurtta <>, hybi <>, Patrick McManus <>, HTTP Working Group <>
X-Mailer: ELM [version ME+ 2.5 PLalpha46]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
X-Filter: 3 received headers rewritten with id 20171110/28661/01
X-Filter: ID 28663/01, 1 parts scanned for known viruses
X-Filter: ID 117954/01, 1 parts scanned for known viruses
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 ( []); Fri, 10 Nov 2017 19:51:54 +0200 (EET)
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 17:52:06 -0000

Takeshi Yoshino <>: (Fri Nov 10 18:51:05 2017)

> 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?

end of connection to client end of connection tells on that case

that server end of connection understand
pseudo header.

It tells nothing about that what is behind of that server end of connection.

Only after request is sent, http response tells if that authority
and path supporting that upgrade. Error is reported as http status code.

I see that reverse proxy can send SETTINGS   ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL)
even when it does not konw if next hop supports that. Support
of next hop or origin server is reported by when that protocol
is triedm failure is reported on http status code.

I assume that that SETTINGS is send on initial server settings
(connection preface SETTINGS).

/ Kari Hurtta