You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now hyper-h2 passes PRIORITY frames to the stream state machine. This is an entirely understandable decision: PRIORITY frames technically are stream-specific and so it makes some degree of sense to want to pass them to that state machine.
However, PRIORITY frames don't actually affect the stream state machine in any way: they can be received and sent on streams in any state (even CLOSED), they cause no state transitions, and in general don't affect the state of any of the stream-level objects. However, they do complicate our stream-level state management because they can inadvertently cause us to resurrect dead streams and generally screw with us.
For this reason, I think we may actually want to hoist the logic for PRIORITY frames up one level to treat them as connection-only frames. This weirdly makes somewhat more sense: the connection has a much better understanding of the way the streams are configured, and while PRIORITY frames are stream-scoped they affect connection state.
This also tentatively affects #157, as the change in handling frames on reset streams applies here.
The text was updated successfully, but these errors were encountered:
Right now hyper-h2 passes PRIORITY frames to the stream state machine. This is an entirely understandable decision: PRIORITY frames technically are stream-specific and so it makes some degree of sense to want to pass them to that state machine.
However, PRIORITY frames don't actually affect the stream state machine in any way: they can be received and sent on streams in any state (even CLOSED), they cause no state transitions, and in general don't affect the state of any of the stream-level objects. However, they do complicate our stream-level state management because they can inadvertently cause us to resurrect dead streams and generally screw with us.
For this reason, I think we may actually want to hoist the logic for PRIORITY frames up one level to treat them as connection-only frames. This weirdly makes somewhat more sense: the connection has a much better understanding of the way the streams are configured, and while PRIORITY frames are stream-scoped they affect connection state.
This also tentatively affects #157, as the change in handling frames on reset streams applies here.
The text was updated successfully, but these errors were encountered: