-
Notifications
You must be signed in to change notification settings - Fork 193
Add ENABLE_PUSH flag in the Upgrade HTTP2-Settings header #310
base: development
Are you sure you want to change the base?
Conversation
Push flag required for the case the initial upgrade request triggered server push.
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.
Thanks for this!
This patch is reasonable, but there are a bunch of tests failing that need to be updated to take account of this change. Do you mind doing that?
I'll look into. |
If enable_push option was not explicitly set, HTTP2-Settings header will not include ENABLE_PUSH option.
fix for `flake8 --max-complexity 15`
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.
So you've fixed some of the test failures, but you're now not actually testing that this data gets emitted. We do need to add a new test to cover this branch.
hyper/http11/connection.py
Outdated
@@ -276,6 +277,9 @@ def _add_upgrade_headers(self, headers): | |||
# Settings header. | |||
http2_settings = SettingsFrame(0) | |||
http2_settings.settings[SettingsFrame.INITIAL_WINDOW_SIZE] = 65535 | |||
if self._enable_push is not None: | |||
http2_settings.settings[ | |||
SettingsFrame.ENABLE_PUSH] = int(self._enable_push) |
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.
Rather than break here, can you do this?
http2_settings.settings[SettingsFrame.ENABLE_PUSH] = (
int(self._enable_push)
)
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.
Yes.
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.
So, as noted, this is not really tested in any sense right now. It would be good to see the appropriate testing changes made.
One travis-ci job is failing unexpectedly with empty raw log. Can I ask help? |
I've restarted that build. =) |
Some tests requires synchronization to let the connection state machine working.
I added http11 h2c upgrading test by inheriting TestServerPush which is for http20 h2, and test passed. |
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.
So, I'm not sure about this approach.
You've added getpushes
to the HTTP11Connection
object with the goal of having it be a dummy method for catching the upgrade. That's understandable, but I'm not sure that this is the way users should be interacting with the abstract method: in particular because if the connection does not upgrade, which the user cannot guarantee will not happen, the response object is lost.
For the purpose of testing it's probably enough to call getresponse
and then check for pushes. How does that sound?
I agree that |
I think those tests don't need to work for upgrade, but we should write a test that does work as expected (e.g. you get a HTTP/2 response and then look for pushes on that stream) |
Push flag required for the case the initial upgrade request triggered server push.