- From: Willy Tarreau <w@1wt.eu>
- Date: Sat, 4 Oct 2025 11:13:40 +0200
- To: ietf-http-wg@w3.org
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