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: signer v4 bug with pre-existing Content-Length header #1729

Closed
wants to merge 1 commit into from
Closed

fix: signer v4 bug with pre-existing Content-Length header #1729

wants to merge 1 commit into from

Conversation

matelang
Copy link

Fixes #1728

@jasdel
Copy link
Contributor

jasdel commented Jun 29, 2022

Thanks for taking the time to create this PR @matelang. I've taken this change and modified it slightly. Reposting it as #1743. We'll get this merged in and included in a future release of the SDK.

@jasdel jasdel closed this Jun 29, 2022
@matelang matelang deleted the v4-signer-fix branch June 29, 2022 08:42
jasdel added a commit that referenced this pull request Jun 29, 2022
…1743)


Fixes the SDK's AWS SigV4 signer to not double sign the content-length header. If the Content-Length header was manually set on the http.Request, that value would be included along with the Request.ContentLength value as a common separated list when computing the string to sign.

This fix updates the signer to always ignore the content-length header, and only use the Request.ContentLength parameter. This change also matches http.Request's behavior of ignoring the Content-Length header if set.

Fixes #1728
Replaces: #1729
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.

V4 Signer incorrect behavior when ContentLength already set
2 participants