Fix CloudFront signer RFC5987 support #3826
Closed
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.
url.parse(someUrl, true)
in combination with nulling itssearch
property has a side-effect when re-encoding usingurl.format
.aws-sdk-js/lib/cloudfront/signer.js
Line 183 in 821e9a1
aws-sdk-js/lib/cloudfront/signer.js
Line 188 in 821e9a1
It causes URL queries existing before the signing process to get re-encoded improperly during the
url.format
stage here:aws-sdk-js/lib/cloudfront/signer.js
Lines 197 to 198 in 821e9a1
This breaks the usage of some special characters in URL queries, even when they have been properly URL encoded. One example is setting the filename in a specific charset using the
response-content-disposition
query field. For example, theresponse-content-disposition
query value (RFC5987 examples) may contain:Although the current functionality returns a signed URL that has the query value formatted as:
This invalidates the generated signature and CloudFront replies with:
To replicate the issue in isolation:
The example input URL query works fine in
aws-sdk-php
andboto3
.Fixes #2952.