Disable payload signing for https requests #6691
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RanVaknin
added
the
no-api-surface-area-change
RanVaknin
commented
Jan 27, 2026
| assertThat(signedRequest.request().firstMatchingHeader("X-Amz-Region-Set")).hasValue("aws-global"); | ||
| assertThat(signedRequest.request().firstMatchingHeader("Authorization")).isPresent(); | ||
| assertThat(signedRequest.request().firstMatchingHeader("x-amz-content-sha256")).contains(PAYLOAD_SHA256_HEX); | ||
| assertThat(signedRequest.request().firstMatchingHeader("x-amz-content-sha256")).hasValue("UNSIGNED-PAYLOAD"); |
Contributor
Author
There was a problem hiding this comment.
Changing default behavior
RanVaknin
commented
Jan 27, 2026
| assertThat(signedRequest.request().firstMatchingHeader("X-Amz-Region-Set")).hasValue("aws-global"); | ||
| assertThat(signedRequest.request().firstMatchingHeader("Authorization")).isPresent(); | ||
| assertThat(signedRequest.request().firstMatchingHeader("x-amz-content-sha256")).contains(PAYLOAD_SHA256_HEX); | ||
| assertThat(signedRequest.request().firstMatchingHeader("x-amz-content-sha256")).hasValue("UNSIGNED-PAYLOAD"); |
Contributor
Author
There was a problem hiding this comment.
Changing default behavior
alextwoods
added
the
perf-improvement
dagnir
reviewed
Jan 27, 2026
...ws/src/main/java/software/amazon/awssdk/http/auth/aws/internal/signer/util/ChecksumUtil.java
Outdated
Show resolved
Hide resolved
...uth-aws/src/main/java/software/amazon/awssdk/http/auth/aws/signer/AwsV4FamilyHttpSigner.java
Outdated
Show resolved
Hide resolved
zoewangg
reviewed
Jan 27, 2026
| if (!isPayloadSigningEnabled) { | ||
| if (payloadSigningEnabled != null) { | ||
| // presigning requests should always have a null payload, and should always be unsigned-payload | ||
| if (!isEncrypted && hasPayload && !payloadSigningEnabled) { |
Contributor
There was a problem hiding this comment.
If payloadSigningEnabled is not null, i.e., configured by the user or set on the service model, should we always enable payload signing regardless of isEncrypted?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Addresses:
JAVA-8739Background
The SDK currently signs payloads for all requests (HTTP and HTTPS). This differs from V1, which only signed payloads for HTTP requests. For HTTPS requests, payload signing is redundant since TLS already provides integrity protection, and it causes measurable performance degradation. This change follows the same behavior of v1 where HTTPS requests' payloads were not signed.
Benchmarking Approach
Performance was measured using JMH with a stubbed DynamoDB client to isolate signing overhead. I chose two binary payload a 10kb and 400kb (DDB limit) to see if this exacerbates the performance bottleneck.
Results
Flamegraphs
Before
After