Lucas Pardue

Parsing schemes complicates the tool and documentation for little benefit

CONTINUATION was just pwned in the wild. If we are adding a similar design, we'll want to hash out all the security considerations up front https://nowotarski.info/http2-continuation-flood-technical-details/

Would the producer of the EA know the size upfront? If so I'd prefer a design where the sender declares the total size of thing, rather than as a set...

Part of the story with CONTINUATION is that endpoints tend to have limits on the size of header field sections that they allow. But CONTINUATION was able to defeat that...

To clarify, does waiving mean ignoring the value of SETTINGS_MAX_FRAME_SIZE when sending or receiving this frame? Such that the maximum length becomes 2^24-1? If so, maybe it would be good...

Still needs a bit more testing / hardening but is ready for initial review

The RFC places requirements for unpredictability and length on the client DCID field; see https://datatracker.ietf.org/doc/html/rfc9000#section-7.2-3 I'm concerned this change can make QUIC connections vulnerable, in ways described in the RFC...

As noted in https://github.com/cloudflare/quiche/pull/2234#issuecomment-3495528844, I think this need to be put behind a feature flag. I'm not willing to make this the default behaviour and risk clients accidentally using the...

The amount of stream data that can be buffered is determined by both flow control and congestion control. stream_capacity() returns the minimum of these. Returning either in isolation risks confusing...

That would risk breaking existing apps