Add more tests for keys with escaped characters #142
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.
Tests are currently failing.
From the SigV4 spec, the path included in the Canonical Request string should have its segments URI encoded.
Both the Java AWS SDK and the AWS CLI will encode the path before sending the request. For example, for the key
a=1
in bucketfoo
the request path would be/foo/a%3D1
. This is both the path used in the Canonical Request (for SigV4) and the path of the actual HTTP request.Playing around with modifying the HTTP path of signed requests I found that Ceph S3 will consider the signature valid even if the path is not encoded. For the example above, Ceph treats
/foo/a%3D1
and/foo/a=1
as equivalent.I think
aws-proxy
should behave the same, decoding the path once and re-encoding when computing the Canonical Request strings.Looks like Jetty doesn't do this by default, which does make sense as most reserved URI characters are allows in paths.