Normalize URI paths during signing (except for S3) (#2018)
* De-dupe multiple leading forward slashes in request This commit fixes a bug reported in https://github.com/awslabs/aws-sdk-rust/issues/661. Note that this de-duping is not part of URI path normalization because it must happen to a request for any service, including S3. * Normalize URI paths for canonical requests This commit enables URI path normalization in aws-sigv4. It follows https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html to create the canonical URI that is part of the canonical request. * Avoid using OS specific path separator This commit updates the implementation of normalize_path_segment so that it does not use an OS specific path separator, specifically "\\" on Windows and always uses a forward slash "/". It addresses a test failure on Windows: https://github.com/awslabs/smithy-rs/actions/runs/3518627877/jobs/5897764889. * Fix the rustdoc::bare_urls warning from cargo doc * Fix a typo Normalzie -> Normalize * Limit de-duping multiple leading forward slashes to S3 This commit addresses https://github.com/awslabs/smithy-rs/pull/2018#issuecomment-1325283254. There is a case where an empty string between leading double forward slashes is meaningful so blindly de-duping them breaks the use case. Therefore, handling multiple leading forward slashes in this manner should be applied only to S3. * Add an integration test per https://github.com/awslabs/aws-sdk-rust/issues/661 This commit adds an integration test verifying the special rule for URI path normalization applies to S3. That is, leading forward slashes should be de-deduped and normalizing URI paths as prescribed in RFC 3986 should be ignored. * Update CHANGELOG.next.toml * Revert 87b749c This commit reverts 87b749c, the reason being that we need to better understand the requirement for de-duplicating leading forward slashes in requests, i.e. do we even need to do it or if so where should we perform the de-dupe operation? * Revert naming of UriPathNormalizationMode variants This commit reverts the naming of variants in UriPathNormalizationMode. They were PerRfc3986 and ForS3, but they should be more generic like Enabled and Disabled as we had before. * Update CHANGELOG.next.toml * Simplify integration test using capture_request This commit simplifies the integration test normalize-uri-path for s3. Previously, the test used ReplayingConnection but it was an overkill to test something as simple as whether the generated request contained the expected URI and signature. * Update aws/rust-runtime/aws-sigv4/src/http_request/settings.rs Co-authored-by:John DiSanti <jdisanti@amazon.com> * Update aws/rust-runtime/aws-sigv4/src/http_request/settings.rs Co-authored-by:
John DiSanti <jdisanti@amazon.com> * Update aws/rust-runtime/aws-sigv4/src/http_request/uri_path_normalization.rs Co-authored-by:
John DiSanti <jdisanti@amazon.com> * Address review feedback on normalize_path_segment This commit addresses the following code review feedback: https://github.com/awslabs/smithy-rs/pull/2018#discussion_r1034192229 https://github.com/awslabs/smithy-rs/pull/2018#discussion_r1034194621 https://github.com/awslabs/smithy-rs/pull/2018#discussion_r1034195625 * Update CHANGELOG.next.toml This commit addresses https://github.com/awslabs/smithy-rs/pull/2018#discussion_r1034198861 * Preallocate the Vec capacity for normalize_path_segment This commit addresses https://github.com/awslabs/smithy-rs/pull/2018#discussion_r1034195625. It counts the number of slashes to preallocate the capacity of a Vec used in normalize_path_segment. * Address https://github.com/awslabs/smithy-rs/pull/2018\#discussion_r1034188849 * Update aws/rust-runtime/aws-sigv4/src/http_request/settings.rs Co-authored-by:
John DiSanti <jdisanti@amazon.com> * Update aws/rust-runtime/aws-sigv4/src/http_request/settings.rs Co-authored-by:
John DiSanti <jdisanti@amazon.com> * Update aws/rust-runtime/aws-sigv4/src/http_request/settings.rs Co-authored-by:
John DiSanti <jdisanti@amazon.com> Co-authored-by:
Yuki Saito <awsaito@amazon.com> Co-authored-by:
John DiSanti <jdisanti@amazon.com>
Loading
Please register or sign in to comment