[quicwg/base-drafts] Consider a new stream type to act like MAX_PUSH_ID (#2418)

[Lucas Pardue <[e-mail]>]

This straw man idea stems from the discussion on #2412.

Consider defining a new unidirectional stream type for Max Push ID updates. This can be expressed as unframed data: a series of increasing var ints. The use of MAX_PUSH_ID frame is entirely, so using a uni stream is a slightly better fit to the concept. Another reason to consider this approach is that it lends itself to extracting server push into an extension. It provides a pattern for how future extensions could manage themselves without needing to pollute the core control stream.

The max Push ID stands out as a connection-level state that has no associated H3 Setting. The reintroduction of an ENABLE_PUSH setting was recently dismissed in Tokyo, for valid reasons.

In this proposal, one client initiated unidirectional stream of type "Max Push ID update" may be created by a client as a clear signal of its interest in enabling server push. Push IDs sent on the stream can only increase in value, any decrease is a *Stream* error of type TBD (possibly just generic HTTP protocol error). Judicious endpoints can upgrade stream error to connection error if they so wish. For reference, closing the H3 control streams is verboten. This solves the problem with the draft 18 text that suggests sending a connection error of MALFORMED_FRAME if a MAX_PUSH_ID frame is received with a value lower than previously seen.

Applying validation at the stream level may be easier to implement, needing only compare next push ID to previous push ID.

One problem with this proposal is that it adds another stream that a server needs to coordinate with. However, server push is already coordinating over the control stream, request streams and push streams.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2418