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

I think this is a great proposal, defining a generic tunneling mechanism
and treating websocket as a special case, with handshake/payload a concern
for Web APIs and frameworks.

Two more notes:
1. as I understand, RFC7540 only states that early 2xx responses are
allowed, i.e. when response headers are generated, any pending request body
becomes insignificant. Therefore the explicit tunneling mechanism is
necessary to signal to proxies/frameworks that a full-duplex byte-stream is
being tunneled as a http/2 stream.
2. with such a generic tunneling mechanism, any TCP based L7 protocol can
be multiplexed over http2, and the explicit handshake (semantically an
inbound RPC)  allows metadata to be exchanged as http/2 headers v.s. using
transport (TCP) headers.


On Wed, Nov 8, 2017 at 6:41 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:

> 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:
>
"HTTP/2 sub-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
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>