Re: Unbound DATA frames in HTTP/3 proposal

On 10/3/25 20:13, 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.

What benefits does that provide?  My understanding is that HTTP/3 *never*
reuses QUIC streams, meaning that the only thing lost by UNBOUND_DATA
is trailer support.  None of the mentioned use-cases care about that,
and they do care about performance.

I'm strongly in favor of this.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)