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

Hi Kazuho,



On Wed, Oct 4, 2023 at 8:56 PM Kazuho Oku <kazuhooku@gmail.com> wrote:

> 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?
>

I tend to agree with your answers. FWIW we obsoleted `h2c` in RFC9113 [1]
so I think making an exception for it (deny list) is fine.

Cheers,
Lucas


[1] = https://www.rfc-editor.org/rfc/rfc9113.html#section-3.1

>
> --
> Kazuho Oku
>