- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Sun, 12 Nov 2017 21:00:07 +0200 (EET)
- To: Kazuho Oku <kazuhooku@gmail.com>
- 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>
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
Received on Sunday, 12 November 2017 19:00:32 UTC