Provide a way to omit "x-amz-content-sha256"-Header creation by AwsV4HttpSigner

[schabe77]

Describe the feature

AwsV4HttpSigner should have an option / signer property that prevents creation of "x-amz-content-sha256"-Header.

Use Case

I currently use software.amazon.awssdk.auth.signer.Aws4Signer to sign my requests to API Gateways. But since it's deprecated I wanted to switch to the proposed software.amazon.awssdk.http.auth.aws.signer.AwsV4HttpSigner.

Unfortunately the requests don't work anymore with the new signer, I always get a "403 Forbidden" response. After having a look at the generated headers I found out that the problem seems to be the "x-amz-content-sha256"-Header that is created by AwsV4HttpSigner (and used for the signature) but not by the deprecated Aws4Signer. Without the header the request works, with the header it doesn't.

I also tried to prevent the payload signing by using .putProperty(AwsV4FamilyHttpSigner.PAYLOAD_SIGNING_ENABLED, Boolean.FALSE) but this only results in a x-amz-content-sha256: UNSIGNED-PAYLOAD header that the API-Gateway also doesn't seem to like.

Proposed Solution

I don't know what to suggest.

I first thought of a new signer property, like CONTENT_HASHING_HEADER_ENABLED.
The problem with a new property could be that it could collide with the existing AwsV4FamilyHttpSigner.PAYLOAD_SIGNING_ENABLED (PAYLOAD_SIGNING_ENABLED=true, CONTENT_HASHING_HEADER_ENABLED=false)

After having a look at the signer classes I found out that the contentHash is a really essential part of the signing process. So actually I don't know how to circumvent the problems that occur when accessing the execute-api

Other Information

Maybe it's already possible to prevent the header. I didn't find a way and my request #5566 wasn't answered.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS Java SDK version used

2.27.20

JDK version used

openjdk version "22.0.2" 2024-07-16

Operating System and version

macOS 14.6.1 (23G93)

[schabe77]

I think the best way to avoid the problem would be for the API gateway to accept the x-amz-content-sha256 header. But I don't know where to make this suggestion.