[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

To: Kazuho Oku <kazuhooku@gmail.com>
Date: Sun, 12 Nov 2017 21:00:07 +0200
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>
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
Precedence: list

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

[hybi] :upgrade? reserve proxies (HTTP/2 to HTTP/… Kari Hurtta