- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Wed, 4 Oct 2023 13:52:24 -0600
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CANatvzxHi7wc44Q_sGXCbBtY=9OYpVugGgQZ107zFxNnNn6hKg@mail.gmail.com>
Hi folks, As a proxy developer, I would like to implement a tunnel for extended CONNECT requests in a HTTP-version agnostic way, without knowing how each protocol as indicated by the :protocol: pseudo header is to be transcoded. The request can come in any HTTP version, then forwarded in any HTTP version. If we look at the existing RFCs and drafts, it seems to me that that's possible. Websocket, connect-udp, connect-ip, connect-ethernet, connect-tcp, they all use GET + upgrade in HTTP/1.1, use extended CONNECT in H2 and H3. Therefore, we can have one shared logic to convert between the HTTP versions that is ignorant of the upgrade token being specified. But because each upgrade protocol defines its own mapping to H1, H2 and H3, the question is: can we assume that we'd be reusing this design pattern so that we can have proxying logic that is agnostic to the upgrade token? Specifically, I think we can break down the question to: 1. Can we transcode H2 extended CONNECT requests to H3, or vice versa? I think the answer is yes. 2. Can we transcode H2 / H3 extended CONNECT requests to H1 GET + upgrade? Maybe the answer is yes. 3. Can we transcode H1 GET + upgrade into H2 / H3 extended CONNECT? I'm not sure if this is possible with h2c. Is it just enough to have a deny list that contains h2c? -- Kazuho Oku
Received on Wednesday, 4 October 2023 19:52:42 UTC