Skip to content

Conversation

@joviegas
Copy link
Contributor

@joviegas joviegas commented Dec 5, 2025

Motivation and Context

PR #6513 moved the ApplyUserAgentStage to execute after MergeCustomHeadersStage. This caused user-supplied User-Agent headers to be overwritten by the SDK's default User-Agent.

Previous behavior: User-supplied User-Agent headers would overwrite the SDK's User-Agent because ApplyUserAgentStage ran before MergeCustomHeadersStage.

After PR #6513: The SDK's User-Agent now overwrites user-supplied User-Agent headers because ApplyUserAgentStage runs after MergeCustomHeadersStage.

This PR fixes the issue by skipping User-Agent modification in ApplyUserAgentStage when a custom User-Agent is already provided via ADDITIONAL_HTTP_HEADERS.

Modifications

  • Added check in ApplyUserAgentStage to detect if User-Agent header exists in ADDITIONAL_HTTP_HEADERS configuration
  • Skip SDK User-Agent application when custom User-Agent is present
  • Added unit tests to verify User-Agent preservation behavior
  • Added functional tests covering various User-Agent configuration scenarios

Testing

  • Added unit tests in ApplyUserAgentStageTest covering: - Custom User-Agent preservation - Empty/null User-Agent handling - User-Agent presence in additional headers
  • Added functional tests in CustomUserAgentHeaderTest covering: - Single and multiple custom User-Agent values - API name handling with custom User-Agent - Edge cases (empty, null, list values)
  • Local run of mvn install succeeds
  • All existing tests pass , tested this with Older version to make sure we are backward compatible before PR Move ApplyUserAgentStage to later stage in request pipeline #6513

Types of changes

  • Bug fix (non-breaking change which fixes an issue)

License

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

@joviegas joviegas requested a review from a team as a code owner December 5, 2025 00:54
@joviegas joviegas force-pushed the joviegas/user_agent_header branch from 65f6dc4 to 05fbba0 Compare December 5, 2025 01:38
@joviegas joviegas force-pushed the joviegas/user_agent_header branch from 05fbba0 to e8b1e16 Compare December 5, 2025 01:47
"type": "bugfix",
"category": "AWS SDK for Java v2",
"contributor": "",
"description": "Skip User-Agent header modification in ApplyUserAgentStage when custom User-Agent is already provided."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is heavy on internal details. Can we simplify so we just say we don't overwrite the custom User-Agent?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks the same, forgot to commit the new file perhaps? 😅

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my bad

public SdkHttpFullRequest.Builder execute(SdkHttpFullRequest.Builder request,
RequestExecutionContext context) throws Exception {

if (hasUserAgentInAdditionalHeaders() || hasUserAgentInRequestHeaders(context)) {
Copy link
Contributor

@dagnir dagnir Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super nit: hasUserAgentInRequestHeaders "inRequestConfig", otherwise it sounds like the header is in the marshalled SdkHttpRequest

@sonarqubecloud
Copy link

sonarqubecloud bot commented Dec 6, 2025

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants