Can proxies forward extended CONNECT in HTTP-version and protocol-agnostic manner?

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