Exclude accept-encoding and hop-by-hop headers from aws_sigv4 signature#546
Merged
wojtekmach merged 2 commits intoMay 22, 2026
Conversation
Owner
|
Thank you! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Hello! This change came out of a production incident we had last night where our signed Cloudflare R2 requests began to fail with 403 responses after a deployment.
We tracked the bug to the introduction of
ezstdin our code base for a separate feature:ezstdis installed,reqaddszstdto theAccept-Encodingheader provided byReq.Steps.compressed/1Accept-Encodingheader is included in the signature, and included in the authorization fieldSignedHeadersAccept-Encoding: gzipon the edge, breaking the signatureAfter looking into other libraries that implement this auth mechanism e.g. boto3, we discovered that they have a list of headers they exclude from the signature.
x-amzn-trace-idwhich can be rewritten by AWS ALBsChanges
aws_sigv4step:x-amzn-trace-id-- can be rewritten by AWS infrastructureauthorization--aws_sigv4creates this so it is not part of the canonical requestaccept-encoding-- excluded because it is commonly rewritten by edge proxiesAlternatives Considered
I had considered moving the
Req.Steps.compressed/1step afterReq.Steps.put_aws_sigv4, rejected since user-suppliedaccept-encodingwould still get signed and hit the same bug. Additionally this change is more brittle since re-ordering this step could have other effects I'm not considering. Not reordering the steps keeps a clean mental model of "signature as the last step".Steps to Reproduce
To reproduce the bug is straightforward:
aws_sigv4, observe 403.compressed: falseon the request and observe 200compressed: false. Observe 200 response.