Re: POST+Upgrade, or unexpected limitation of RFC8441

On Wed, Dec 18, 2024 at 11:10:32AM +0000, Lucas Pardue wrote:
> I also found it funny to observe in the docker documentation the section
> onn interactive sessions [1], with our old fried h2c upgrade
> 
> > This endpoint hijacks the HTTP connection to HTTP2 transport that allows
> the client to expose gPRC services on that connection.
> 
> RFC 7540 has the following to say about h2c upgrade [2]:
> 
> > Requests that contain a payload body MUST be sent in their entirety
> before the client can send HTTP/2 frames. This means that a large request
> can block the use of the connection until it is completely sent.
> 
> Anyone got the history about why that text was added?

I'm pretty sure that the intent was simply to deal with the need to
establish a connection on a POST. Given that the h1->h2 upgrade was
designed to be opportunistic, (both sides opt in, neither being able
to request it), it makes sense to support POST hence it forces this
requirement.

This means that there's at least one paragraph in a standard that de-
facto confirms the need for Upgrade to support a payload and deal with
it like any other request, and that 8441 is missing that part, so maybe
that could fuel the preference for explicitly supporting content-length
with :protocol.

Willy

Received on Wednesday, 18 December 2024 13:18:12 UTC