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

Hi Patrick,

2017-11-02 20:27 GMT+09:00 Patrick McManus <pmcmanus@mozilla.com>:
> Here are my plans for -02
>
> * websockets parameters (sub-protocol, etc..) into h2 HEADERS
>
> * define the websockets target URI scheme for CONNECT as being http/https
> when using 6455. I actually think this is a change from 6455 but I can live
> with it if its defined. Mostly the concern is around legacy pac.
>
> * stick with CONNECT as the method for the moment.. my thinking here is that
> CONNECT is already a strange beast with special code doing almost what we
> want here anyhow.. replicating that is not great. I would rather have a
> pseudo header be the version specific thing (which is expected of pseudo
> headers) than adding a new method which is typically not.

This might be unnecessary, but I wonder if it's worth adjusting the
approach so that it could be converted into a generic way of upgrading
an HTTP/2 stream into a bidirectional channel.

To me it seems that we are removing almost all features specific to
WebSocket. The only things remain specific are:

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

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.

The approach might be overly generic than what we need. OTOH, having a
generic mechanism help us, because we would no longer need to have any
protocol-specific code in a reverse proxy. Hence asking about the
possibility.

-- 
Kazuho Oku

Received on Thursday, 9 November 2017 02:41:46 UTC