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

Fix auth error when resigning requests #379

Merged
merged 4 commits into from
Nov 17, 2014
Merged

Conversation

jamesls
Copy link
Member

@jamesls jamesls commented Nov 17, 2014

More fallout from reusing the same request object to resign
a request. Before setting a value for a header, we need to first
check if the key exists and delete it first, otherwise it's an
append, not a replace, which will cause signing errors.

Though not strictly required for some signers, I think it's important
to be consistent and just state that before setting a header value,
we should delete it first if it exists.

Couple of other things I noticed:

  • Clients aren't plumbed into retry logic. I moved the event registration
    over to service-data-loaded in the hopes that we can make this accessible
    to the client interface
  • To ensure we can retry as expected I've updated our smoke test with a new
    suite of tests. These tests mock out the HTTPAdapter such that the first
    attempt to send the request always triggers a ConnectionError (the second
    attempt calls the original send() method). This ensures we are retrying
    requests properly for all the services in the smoke tests.

cc @kyleknap @danielgtaylor

Makes it (almost) possbile to support retries in the client
interface as well.
More fallout from reusing the same request object to resign
a request.  Before setting a value for a header, we need to first
check if the key exists and delete it first, otherwise it's an
append, not a replace, which will cause signing errors.

Though not strictly required for some signers, I think it's important
to be consistent and just state that before setting a header value,
we should delete it first if it exists.
@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling 7fa0f01 on jamesls:verify-retries into 4d9ea82 on boto:develop.

@danielgtaylor
Copy link
Member

LGTM 🚢-it!

@@ -380,7 +384,7 @@ def base64_encode_user_data(params, **kwargs):
('needs-retry.s3.CopyObject', check_for_200_error, REGISTER_FIRST),
('needs-retry.s3.CompleteMultipartUpload', check_for_200_error,
REGISTER_FIRST),
('service-created', register_retries_for_service),
('service-data-loaded', register_retries_for_service),
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this because the clients do not hit the 'serivce-created' event? Just curious.

Copy link
Contributor

Choose a reason for hiding this comment

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

Nevermind, just read the overview of the PR. Question answered.

@kyleknap
Copy link
Contributor

It looks good to me. 🚢 I just had a question about the assertion for one of the unit tests.

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.

4 participants