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

Support the use of a Session object #14

Merged
merged 5 commits into from Nov 19, 2017

Conversation

oliverlockwood
Copy link
Contributor

Closes #13.

A couple of things are worth highlighting up-front - I'll comment on these inline.

@@ -12,6 +12,7 @@
DEFAULT_POLLING_INTERVAL = 2 # in seconds
DEFAULT_MAX_RETRIES = 50
VALID_CONDITIONS = ['status_code', 'json', 'jsonpath', 'text', 'callback']
DEFAULT_SESSION = requests.Session()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since our PreparedRequest now comes from self.session.prepare_request(self.request) instead of self.request.prepare() - see below - there is a behavioural change in the default case (no Session explicitly provided).

  • From the links above, you can see that this involves merging in Session default headers, cookies, params, auth, and hooks. Of these, params and auth default to empty / none; I think the only interesting possibilities are around cookies and headers.
  • If we consider the behavioural change acceptable, then we're good. If on the other hand we want to ensure no behavioural change, we can change the definition of DEFAULT_SESSION to override cookies and headers to empty dictionaries. Your call.
  • Additionally (Python style question) should DEFAULT_SESSION be a method rather than an instance variable? I worry that the lack of immutability means that somebody could accidentally change DEFAULT_SESSION and unintentionally affect other uses of it.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 95.313% when pulling 65ec4a4 on oliverlockwood:support-session into 1a5e76d on kopf:master.

2 similar comments
@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 95.313% when pulling 65ec4a4 on oliverlockwood:support-session into 1a5e76d on kopf:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 95.313% when pulling 65ec4a4 on oliverlockwood:support-session into 1a5e76d on kopf:master.

args, kwargs = mock_adapter_send.call_args
assert args[0].headers == {'Content-Type': 'test/type', 'Cookie': 'tasty-cookie=chocolate'}
assert 'verify' in kwargs
assert kwargs['verify'] == '/session/verify'
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Initially, this test continued to fail even after I'd implemented the functionality.

The test case is where the session includes a specific value for verify, but the user doesn't directly specify a value in the HttSleeper API. Unfortunately, the session value was being ignored, and verify=True was being used instead, running counter to the standard behaviour of the requests library.

Thus I was forced to revisit the discussion we had in #12 (comment) about whether HttSleeper should by default send verify=True or leave the kwarg unspecified. That's why my 4th commit changes this behaviour back to that which I originally proposed in the last PR 😃

Copy link
Owner

Choose a reason for hiding this comment

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

Aha, ok! Sorry for the back-and-forth, but at least the end result sounds perfect.

@oliverlockwood
Copy link
Contributor Author

Hi @kopf, any chance of a review of this one when you have the chance? Many thanks.

@kopf
Copy link
Owner

kopf commented Nov 17, 2017

yup, it's on my todo list, extremely stressful time at work at the moment, will have a look at the weekend

@oliverlockwood
Copy link
Contributor Author

No worries!

session = requests.Session()
session.cookies = {'tasty-cookie': 'chocolate'}
session.headers = {'Content-Type': 'test/type'}
session.verify = '/session/verify'
Copy link
Owner

Choose a reason for hiding this comment

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

Should be a boolean, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can be either a boolean or a string also - see https://github.com/requests/requests/blob/master/requests/api.py#L39-L41.

I thought it was worth having at least one or two non-boolean cases in the tests.

Copy link
Owner

Choose a reason for hiding this comment

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

Aha! I wasn't aware. OK, it's grand so

httsleep.run()
assert mock_adapter_send.called
args, kwargs = mock_adapter_send.call_args
assert args[0].headers == {'conflict-header': 'req-wins', 'req-header': 'myRequest', 'session-header': 'mySession'}
Copy link
Owner

Choose a reason for hiding this comment

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

Cool!

def test_request_verify_overrules_session_verify():
"""Should give precedence to the 'verify' setting in the request, over that in a specified Session"""
session = requests.Session()
session.verify = '/path/to/ca/bundle'
Copy link
Owner

Choose a reason for hiding this comment

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

Could we not set this to True and then do

httsleep = HttSleeper(URL, {'status_code': 200}, session=session, verify=False)

And then check whether verify is False?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That would of course work, but:

  • as per my other comment, verify can be a string as well
  • I thought it improved readability of the test to have the overriding value of /override/path.

I can change it to a boolean case if you'd prefer, just say the word.

Copy link
Owner

Choose a reason for hiding this comment

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

Yep, grand, leave it as it is

@kopf
Copy link
Owner

kopf commented Nov 19, 2017

Great stuff!

All that's missing is a changelog entry.

@kopf
Copy link
Owner

kopf commented Nov 19, 2017

And you need to update the documentation - the "Polling" section of tutorial.rst in particular. It would be good to mention the use case (polling using different requests, but inside the same session so that they all get the same headers and cookies). I'd put it straight after the "polling using a POST request" example.

@oliverlockwood
Copy link
Contributor Author

@kopf tutorial & changelog entries now added, please let me know if they need tweaking at all.

@coveralls
Copy link

coveralls commented Nov 19, 2017

Coverage Status

Coverage increased (+0.1%) to 95.313% when pulling ff4a601 on oliverlockwood:support-session into 1a5e76d on kopf:master.

@oliverlockwood oliverlockwood mentioned this pull request Nov 19, 2017
@kopf
Copy link
Owner

kopf commented Nov 19, 2017

LGTM, thanks again!

@kopf kopf merged commit 96ad441 into kopf:master Nov 19, 2017
@oliverlockwood oliverlockwood deleted the support-session branch November 20, 2017 07:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants