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

Hi folks,

The original analysis seems to focus on the request and response. For
those, I agree with your analysis. However, things get more complicated
after the protocol tunnel is established. In h1 and h2, the only available
HTTP-transport-layer elements are a bidirectional byte stream, so proxying
the bytes unmodified should be safe. In h3, it gets more complicated
because of things like datagrams. Now if you just blindly copy the request
stream's bytestream, you're losing semantic value. (Note that this also
applies to h2, as one could in theory write an extension to h2 that defines
new capabilities at the h2 framing layer.) As Ben points out, an
implementation that supports RFC 9297 could look at datagrams and the
Capsule-Protocol header, but that doesn't help with other extensions.
Another example is WebTransport and the way it ties other QUIC streams to
the WebTransport session.

So, if the goal is to build an intermediary that translates automatically
between HTTP versions without understanding the protocol, it will fail any
time a new extension to HTTP itself is required for a protocol to operate.
But that's not a deal breaker, just something to consider. Those extensions
to HTTP require settings, so the client shouldn't be using those protocols
if the intermediary hasn't sent the corresponding setting. So I guess it
comes down to: if an intermediary wants to do this, it really needs to
properly handle translating all of the extensions that it supports.

To throw one more wrench into these gears, the Capsule-Protocol header was
unfortunately defined to be optional so an intermediary that receives
HTTP/3 :protocol=connect-udp but without Capsule-Protocol=?1 won't know
what to do with datagrams it receives. I vaguely remember that the intent
of the proponents of making Capsule-Protocol optional was explicitly to
prevent doing this type of conversion.

Anyway, apologies for the long ramble. Based on all this, it's probably not
safe to convert unknown HTTP upgrade tokens between HTTP versions.

David

On Wed, Oct 4, 2023 at 1:56 PM Ben Schwartz <bemasc@meta.com> wrote:

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