Re: Unbound DATA frames in HTTP/3 proposal

On Sat, Oct 04, 2025 at 01:13:00PM +1300, Amos Jeffries wrote:
> On 04/10/2025 10:33, Lucas Pardue wrote:
> > Hi,
> > 
> > Thanks for the proposal. While the use case(s) might seem niche, I think
> > there are enough avenues that could benefit from such an extension.
> > 
> > HTTP/3 framing, while powerful, is a common impediment to more optimized
> > data paths that HTTP/1.1 can leverage.
> > 
> > The use cases described such as CONNECT streams are "odd" in HTTP terms
> > anyway and already don't allow for things like trailers. This extension
> > spells that existing reality in a different way.
> > 
> > In some ways, this reminds me of proxy protocol v2 [1]. A binary format
> > for header containing some useful info, before switching into full byte
> > streaming mode.
> > 
> 
> So all the HTTP/2 work to fix unbound-data completion-vs-termination issues.
> Then HTTP/3 to migrate to UDP/QUIC. Only to revert to essentially HTTP
> 0.9/1.0 messaging semantics over QUIC.
> 
> IMHO code that is new enough to properly wrap a octet sequence in QUIC
> syntax (for the 'unbounded' delivery), is better off wrapping it as normal
> HTTP DATA instead.

I must confess I'm having a hard time seeing the effective benefits as well.
If the bytes were sent from H3 directly to the wire I could understand the
benefit of the possible zero-copy approach (e.g. using sendfile() directly
to a socket), but here it's not the case, QUIC frames will have to be built
anyway so the copy cannot be avoided.

As explained in the draft, it's losing the possible benefits of trailers
which can explain why the connection stops.

In fact I'm seeing the proposal more as a protocol upgrade (replace H3
with something else) over the QUIC stream rather than unbounded data,
because it's effectively what is happening: past that empty frame, it
could simply be a different protocol. And I suspect that the real needs
it tries to cover are precisely to use H3 to upgrade to another protocol
(WS, WT), not really just send infinite data in the context of an H3
request. If so, shouldn't we define how to upgrade H3 to something else?

At least it would clarify the fact that the upgrade is bidirectional
and synchronized between the two directions, because here it's not the
case and I doubt there are many realistic use cases for sending regular
H3 in one direction and unbound data in the other one.

Regards,
willy

Received on Saturday, 4 October 2025 09:13:46 UTC