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

> Am 04.10.2023 um 21:52 schrieb Kazuho Oku <kazuhooku@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.

Just as a data point: Apache httpd is doing this for WebSockets. The Extended h2 CONNECT is converted to a h1 GET internally with Sec-WebSocket-Key header. The 101 response is converted to 200, etc. etc.

- Stefan

> 
> 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 Thursday, 5 October 2023 06:29:46 UTC