cloudflare
h3: extend support for unknown frames
We already had support for reading unknown frame times out of a stream, per the requirements of RFC 9114.
This change adds support for capturing the frame payload while reading rather than discarding it. This is useful for low-level or debug purposes.
We also add support for serializing "unknown" frames, allowing a raw type and an opaque payload to be converted to a wire format. Again this is useful for low-level or debug purposes.
Most HTTP/3 applications won't need these capabilities, so they are not exposed via any API changes.
Perhaps this makes more sense as a separate PR, but exposing unknown frame types via poll would be useful in testing things like https://datatracker.ietf.org/doc/draft-egorbaty-httpbis-secondary-server-certs/
Definately out of scope for this PR :)
We discussed this a long time ago. There's not that many extensions where random frame types are jsut sent without affecting some level of connection or stream state. In this case of secondary certs, there's SETTINGS_HTTP_SERVER_CERT_AUTH to contend with first, and then the rule that The CERTIFICATE frame MUST be sent on the control stream.. Exposing any unknown frame on any stream to apps now puts a burden on them to read that frame and discard it, which seems a bit lame. More so if they don't enforce rules by accident.
Past decisions aren't forever though. The work in https://github.com/cloudflare/quiche/pull/1555 allows a little more flexibility for SETTINGS. @francoismichel and I have discussed ways to allow a bit of control over unknown unidirectional stream types. Maybe we could think about adding some way to register explicit interest in particular extension frames so that quiche could pass them up to apps that opt-in.