Fix for Issue #3569 where the user set Content-Encoding was over writ…

[joviegas]

Motivation and Context

Fix for Issue 3569

Modifications

Checksum related interceptors and signers did a putHeader which over wrote the content-encoding header instead of overwriting it, Thus appendHeader is used in these places.

-DefaultAwsCrtS3V4aSigner

• AbstractAwsS3V4Signer
• AsyncRequestBodyHttpChecksumTrailerInterceptor
• SyncHttpChecksumInTrailerInterceptor

Fix

• The sdk will append the aws-chunked content-header value. Thus if user has set the content header as gzip then sdk will send this header as multiple header as mentioned in https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-streaming.html

Amazon S3 supports multiple content encodings. For example:
Content-Encoding : aws-chunked,gzip
That is, you can specify your custom content-encoding when using Signature Version 4 streaming API.

Testing

• Added Junits
• Aded integ test

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

License

• I confirm that this pull request can be released under the Apache 2 license

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

88.9% Coverage
0.0% Duplication

[L-Applin]

Code looks good, but there are some things I'm confused about. Is this quote from the issue still correct?

Expected Behavior
Content-Encoding header should remain unset when using ChecksumAlgorithm.

Because, maybe Im not understanding correctly, it seems we are fixing an issue that overwrites the Content-Encoding, but does not address the fact that it has an empty value? Does the Header needs to be unset or have the aws-chunked value.

[joviegas]

Code looks good, but there are some things I'm confused about. Is this quote from the issue still correct?

Expected Behavior
Content-Encoding header should remain unset when using ChecksumAlgorithm.

Because, maybe Im not understanding correctly, it seems we are fixing an issue that overwrites the Content-Encoding, but does not address the fact that it has an empty value? Does the Header needs to be unset or have the aws-chunked value.

The user is trying to say AWS-sdk-java should not overwrite(reset) the User set Cheunked endcoding value. The unset more of means "over write" here.
With the fix we will be appending the "aws-chunked" header and not reset/overwrite while sending the User set value to S3

, it seems we are fixing an issue that overwrites the Content-Encoding, but does not address the fact that it has an empty value?

Yeap , with the current fix we are not addressing what user sends in Content-Encoding , we are just appending to the header since as part of Checksums for trailers we just need to specific "aws-chunked" and not modify user sent valid/invalid entries for Content-Encoding

Does the Header needs to be unset or have the aws-chunked value.

Nope , we donot need to do any operation on User value just Append aws-chunked to any existing value