[hybi] :upgrade? reserve proxies (HTTP/2 to HTTP/1.1) | Re: Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Sun, 12 November 2017 19:00 UTC

Return-Path: <khurtta@welho.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD9B124C27 for <hybi@ietfa.amsl.com>; Sun, 12 Nov 2017 11:00:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQXmJ1b5GtaI for <hybi@ietfa.amsl.com>; Sun, 12 Nov 2017 11:00:11 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995A01243FE for <hybi@ietf.org>; Sun, 12 Nov 2017 11:00:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D640C97B56; Sun, 12 Nov 2017 21:00:07 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id w3iCtaijmgGu; Sun, 12 Nov 2017 21:00:07 +0200 (EET)
Received: from hurtta09lk.keh.iki.fi (89-27-39-95.bb.dnainternet.fi [89.27.39.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPS id E94C22313; Sun, 12 Nov 2017 20:59:58 +0200 (EET)
To: Kazuho Oku <kazuhooku@gmail.com>
Date: Sun, 12 Nov 2017 21:00:07 +0200 (EET)
Sender: hurtta@hurtta09lk.keh.iki.fi
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Patrick McManus <pmcmanus@mozilla.com>, Andy Green <andy@warmcat.com>, John Fallows <john.fallows@kaazing.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-Mailer: ELM [version ME+ 2.5 PLalpha46+]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20171112190007.D640C97B56@welho-filter4.welho.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/sP_JilhTPsK61Id_2MAK6Xnh76c>
Subject: [hybi] :upgrade? reserve proxies (HTTP/2 to HTTP/1.1) | Re: Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Nov 2017 19:00:14 -0000

https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0209.html

> * use of `CONNECT` as the method; having one method would be fine for
> websocket (since it only allows the use of `GET`), but that is not
> case for other upgrades (e.g. HTTP/2)
> * not using 101 as a way to notify protocol change
> * no way to specify which non-end-to-end header is required for
> upgrade (e.g. HTTP2-Settings)
> 
> If we adjust the three issues (for example, by allowing any method to
> be specified, and use the existence of :upgrade: pseudo header as a
> signal; use 101 to signal protocol change; use attributes of :upgrade:
> header to specify additional headers required for the upgrade), I

I was difficulties to interpret this

"use attributes of :upgrade: header to specify additional headers required 
for the upgrade"

> think the approach would become generic.
> 
> For example, creating a websocket tunnel through HTTP/2 would look like below.
> 
> Request:
>  :method: GET
>  :scheme: https
>  :authority: server.example.com
>  :path: /chat
>  :upgrade: websocket
>  sec-websocket-key: dGhlIHNhbXBsZSBub25jZQ==
>  origin: http://example.com
>  sec-websocket-protocol: chat, superchat
>  sec-websocket-version: 13
>  <data is same as RFC6455>

   If attributes of :upgrade: header to specify additional headers required
   for the upgrade, then this look like

    :upgrade: websocket; sec-websocket-key; sec-websocket-protocol; sec-websocket-version

   But you not really mean that.

> Response:
>  :status: 101
>  :upgrade: websocket
>  sec-websocket-accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
>  sec-websocket-protocol: chat
>  <data is same as RFC6455>
>
> Or in case of upgrading an HTTP/2 stream to HTTP/2 connection:
> 
> Request:
>  :method: GET
>  :scheme: http
>  :authority: server.example.com
>  :path: /
>  :upgrade: h2c; http2-settings
>  http2-settings: <base64url encoding of HTTP/2 SETTINGS payload>
>  <may contain request body>
>
> Response:
>   :status: 101
>   :upgrade: h2c
>   <data is same as RFC7540>
> 
> In this example, the :upgrade: pseudo header is used to convey the
> connection headers required for upgrade (as the following elements of
> the header field value), so that a reverse proxy receiving the request
> could convert it to an HTTP/1 request with a "Connection: upgrade,
> http2-settings" header.

 That ":upgrade: pseudo header is used to convey the connection headers required 
 for upgrade" tells what you mean, but that is different than additional headers 
 required for the upgrade.


Yes. It make sense that :protocol or :upgrade is specified that way that
reverse proxy can do HTTP/2 ⇒ HTTP/1.1 Upgrade:  conversion without
knowing details of upgraded protocol.

I think that this is useful property. HTTP/2 is soemtimse terminated
on reverse proxy and forwarded as HTTP/1.1 to back end servers.

/ Kari Hurtta