Re: POST+Upgrade, or unexpected limitation of RFC8441

Hi Ben,

[sorry, I seem to have missed your response]

On Wed, Dec 18, 2024 at 07:28:41PM +0000, Ben Schwartz wrote:
> It seems like the underlying confusion here comes from two false (but
> understandable!) assumptions:
> 
> 1. The ":protocol" pseudoheader's value is an Upgrade Token, so it can
> contain any Upgrade Token.
> 2. It is possible to convert HTTP/1.1 Upgrade to Extended CONNECT generically.
> 
> In fact, ":protocol" only supports a subset of the registered Upgrade Tokens
> (i.e. those that explicitly describe their use with Extended CONNECT), and
> even if an Upgrade Token is defined for use in both HTTP/1.1 Upgrade and
> Extended CONNECT, there is no generic process for converting between these
> forms without detailed knowledge of the specific Upgrade Token.

My perception was that this extension was meant to be more generic. Section
4 (The Extended CONNECT) doesn't put any reserve regarding the supported
protocols. Section 5 applies it to WebSocket.

We're still in a situation where it's impossible to safely transport
HTTP/1 over HTTP/2, which is a problem because some users are blocked
"in the past".

> I wish it were otherwise.  And in fact, I think we could fix this for a
> subset of Upgrade Tokens (those that use the Capsule Protocol):
> https://datatracker.ietf.org/doc/html/draft-kb-capsule-conversion-00
> 
> That's not going to help you with whatever Docker is doing though.  Someone
> should tell them that "tcp" is not a registered Upgrade Token [1] and "h2c"
> is deprecated.

I agree with that to some extents, because Upgrade is a cleaner CONNECT,
actually one that can decide whether or not to upgrade based on path,
query string, and/or header fields. So I understand why users want to
use Upgrade instead of CONNECT. That was also one of the reasons for WS
to adopt it by the way. They could register a valid name but the problem
would persist.

> As for haproxy, it needs to restrict its HTTP Version Conversion logic to
> recognized Upgrade Tokens where the conversion logic is known to be correct.

For H1 to H1 that's definitely not acceptable because users expect
intermediaries to work when placed between a client and a server. We've
seen various upgraded protocols over the years, from unknown applications
to remote terminals etc. Users often have noo idea what protocol is
involved. What we've done for now is to only block h2c, which is the
one known to let a client and server agree to bypass the intermediary.

For H1 to H2, we're indeed more limited in that we can't pass a POST
to H2 since CONNECT doesn't permit to upload contents. Even if a token
was registered as an upgrade token, it would continue to work fine for
H1 but fail for H2 as soon as it's used as a POST.

That's why I'm saying that I'm not sure there's a definitive solution
to this situation, but we should at minima note this incompatibility
somewhere and keep in mind for future extensions that till now we
failed to fully transport H1 over H2, and that this specific use case
(upgrade after consuming the request payload) should be kept in mind
for completeness.

Regards,
Willy

Received on Thursday, 26 December 2024 10:00:31 UTC