-
Notifications
You must be signed in to change notification settings - Fork 63
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
ignore management frames for a period after closing a connection #140
Changes from 2 commits
75253c8
3f0cf83
445963b
9224cee
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -542,6 +542,13 @@ | |
expect { @conn.new_stream }.to raise_error(ConnectionClosed) | ||
end | ||
|
||
it 'should not raise error when receiving connection management frames after closing' do | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "should not raise error when receiving connection management frames immediately after emitting goaway"? Any merit in wiring up tests for one or two other types of frames? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. just added. |
||
@conn.goaway | ||
expect(@conn).to be_closed | ||
|
||
expect { @conn << f.generate(PING.dup) }.not_to raise_error(ProtocolError) | ||
end | ||
|
||
it 'should process connection management frames after GOAWAY' do | ||
@conn << f.generate(SETTINGS.dup) | ||
@conn << f.generate(HEADERS.dup) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, what you wired up here makes sense. 👍
One question I have is.. Current logic will cover {settings, window_update, ping, goaway} connection management frames. What about other types of frames, do we need to do anything there? Per #139 (comment)...
Anything else / special we need to think about with respect to the above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say it's already covered here, here or here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. One corner case here is that we'll be ignoring all frames, irrespective of their ID being established before or after GOAWAY is emitted, but that's probably OK. If that surfaces as an issue, we can revisit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is true, and I thought about that. One should throw protocol error for when a stream id is higher than the last stream id from the goaway frame. But I thought that was out of scope. Am I wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's worth leaving a comment in the source, stating that we're not enforcing this behavior. I don't think we need to block this PR on implementing that though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
after reading better, I think I advised for something which is not RFC-compliant. I think this PR covers everything necessary.