- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Thu, 9 Nov 2017 11:41:22 +0900
- To: Patrick McManus <pmcmanus@mozilla.com>
- Cc: Andy Green <andy@warmcat.com>, John Fallows <john.fallows@kaazing.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CANatvzzdd6cr+Z=oLh=kU7PUTio2MGhdM2eppcUZkCjchNLHmQ@mail.gmail.com>
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