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

I think conversions between HTTP/2 and HTTP/1.1 would require a new standards-track RFC to codify the usage of "GET" (and possibly revise our interpretation of the "HTTP" and "TLS" upgrade tokens), but otherwise it should be fine.  That document would have to incorporate some requirements related to https://datatracker.ietf.org/doc/draft-schwartz-httpbis-optimistic-upgrade/, which hasn't gotten enough comments yet.  Please review!

Conversions involving HTTP/3 are more interesting due to datagrams.  If the Capsule-Protocol header is present, then conversions between H2 and H3 are well-defined.  Otherwise, I don't think it's safe: the H3 hop could send a datagram, and the H2 hop wouldn't know what to do with it.  Silently blackholing all datagrams, on a request that claims to be successful, is not a good solution.

--Ben Schwartz

________________________________
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Sent: Wednesday, October 4, 2023 4:01 PM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
Hi Kazuho,



On Wed, Oct 4, 2023 at 8:56 PM Kazuho Oku <kazuhooku@gmail.com<mailto: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<https://www.rfc-editor.org/rfc/rfc9113.html#section-3.1>

--
Kazuho Oku