Skip to content
This repository has been archived by the owner on Jan 13, 2021. It is now read-only.

Add ENABLE_PUSH flag in the Upgrade HTTP2-Settings header #310

Open
wants to merge 11 commits into
base: development
Choose a base branch
from

Conversation

hkwi
Copy link
Contributor

@hkwi hkwi commented Feb 21, 2017

Push flag required for the case the initial upgrade request triggered server push.

Push flag required for the case the initial upgrade request
triggered server push.
Copy link
Member

@Lukasa Lukasa left a 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?

@hkwi
Copy link
Contributor Author

hkwi commented Feb 21, 2017

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`
Copy link
Member

@Lukasa Lukasa left a 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.

@@ -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)
Copy link
Member

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

Copy link
Member

@Lukasa Lukasa left a 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.

@hkwi
Copy link
Contributor Author

hkwi commented Feb 22, 2017

One travis-ci job is failing unexpectedly with empty raw log. Can I ask help?

@Lukasa
Copy link
Member

Lukasa commented Feb 22, 2017

I've restarted that build. =)

Some tests requires synchronization to let the connection
state machine working.
@hkwi
Copy link
Contributor Author

hkwi commented Feb 23, 2017

I added http11 h2c upgrading test by inheriting TestServerPush which is for http20 h2, and test passed.

Copy link
Member

@Lukasa Lukasa left a 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?

@hkwi
Copy link
Contributor Author

hkwi commented Feb 23, 2017

I agree that HTTP11Connection.getpushes is a little bit hacky. This was added to meet the strict tests of test_promise_before_headers or test_capture_all_promises. If we don't need to satisfy these tests for http11 upgrade, implementation would be more relaxed style. I'll create another PR for that version later.
BTW, the response will be stored in self._response for later self.get_response call, and would not lost.

@Lukasa
Copy link
Member

Lukasa commented Feb 23, 2017

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)

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

Successfully merging this pull request may close these issues.

2 participants