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

ignore management frames for a period after closing a connection #140

Merged
merged 4 commits into from
Aug 31, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions lib/http/2/connection.rb
Original file line number Diff line number Diff line change
Expand Up @@ -94,6 +94,7 @@ def initialize(**settings)
@error = nil

@h2c_upgrade = nil
@closed_since = nil
end

def closed?
Expand Down Expand Up @@ -144,6 +145,7 @@ def goaway(error = :no_error, payload = nil)
send(type: :goaway, last_stream: last_stream,
error: error, payload: payload)
@state = :closed
@closed_since = Time.now
end

# Sends a WINDOW_UPDATE frame to the peer.
Expand Down Expand Up @@ -446,12 +448,15 @@ def connection_management(frame)
# the connection, although a new connection can be established
# for new streams.
@state = :closed
@closed_since = Time.now
emit(:goaway, frame[:last_stream], frame[:error], frame[:payload])
when :altsvc, :blocked
emit(frame[:type], frame)
else
connection_error
end
when :closed
connection_error if (Time.now - @closed_since) > 15
Copy link
Owner

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)...

After sending a GOAWAY frame, the sender can discard frames for
streams initiated by the receiver with identifiers higher than the
identified last stream. However, any frames that alter connection
state cannot be completely ignored. For instance, HEADERS,
PUSH_PROMISE, and CONTINUATION frames MUST be minimally processed to
ensure the state maintained for header compression is consistent (see
Section 4.3); similarly, DATA frames MUST be counted toward the
connection flow-control window. Failure to process these frames can
cause flow control or header compression state to become
unsynchronized.

Anything else / special we need to think about with respect to the above?

Copy link
Collaborator Author

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.

Copy link
Owner

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.

Copy link
Collaborator Author

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?

Copy link
Owner

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.

Copy link
Collaborator Author

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.

else
connection_error
end
Expand Down
9 changes: 9 additions & 0 deletions spec/connection_spec.rb
Original file line number Diff line number Diff line change
Expand Up @@ -542,6 +542,15 @@
expect { @conn.new_stream }.to raise_error(ConnectionClosed)
end

it 'should not raise error when receiving connection management frames immediately after emitting goaway' do
@conn.goaway
expect(@conn).to be_closed

expect { @conn << f.generate(SETTINGS.dup) }.not_to raise_error(ProtocolError)
expect { @conn << f.generate(PING.dup) }.not_to raise_error(ProtocolError)
expect { @conn << f.generate(GOAWAY.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)
Expand Down