Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider PRIORITY frame state machine flow. #168

Closed
Lukasa opened this issue Feb 9, 2016 · 0 comments
Closed

Reconsider PRIORITY frame state machine flow. #168

Lukasa opened this issue Feb 9, 2016 · 0 comments

Comments

@Lukasa
Copy link
Member

Lukasa commented Feb 9, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant