Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
ISSUE #240: Fix signing issues for endpoints with a path component #242
I have to admit, going into this, I didn't fully understand the intent of IRequest.ResourcePath as it relates to IRequest.Endpoint.
The closer I look at the code, I'm wondering if the signers should be using AmazonServiceClient.ComposeUrl() as a means to resolve the URL that ultimately gets canonicalized.
Do you agree? If so, the PR should be revised.
When I ran the integration tests we had a couple of fails in a test which validate some S3 keys we've had issues with in the past. You can find the test class in sdk\test\IntegrationTests\Tests\S3\KeyNameTests.cs called TestKeyNameWithAwkwardChars_AWS4Signing if you want to take a look.
The two keys that triggered fails are:
In the first case, the use of Uri.AbsolutePath returns 'ObjectWith!and', terminating on the ? character. In the second case the Uri class is encoding the \ before we get a chance to work with the url in canonicalization and as a result we end up working with a double-encoding (this has been a common problem for use with use of the Uri class, which is why we tend to prefer string manipulation for urls for as long as possible).
Do you want to take another look at the fix in light of these two keys? The rest of the integration test suite ran without any issues.
I addressed the problematic keys by grabbing the unescaped path from the composed request URL and feeding it to the original logic of "CanonicalizeResourcePath."
I ran the failing integration test using my account and verified that it now passes.
Let me know! :)