Do not sign X-Forwarded-For header if present on the request

[brandondahler]

Motivation and Context

Currently, AWS SDKs sign most custom headers, including the X-Forwarded-For header, during SigV4 authentication, causing signature validation failures in specific scenarios.

In some rare cases related to building application-layer proxies (in my case, specifically for CloudWatch RUM), attempting to add a X-Forwarded-For header by any normal method results in a InvalidSignatureException. This is because X-Forwarded-For is a hop-by-hop header that many reverse proxies modify (presumably including the reverse proxies used by CloudWatch RUM).

This change proposes to stop signing the X-Forwarded-For header with SigV4(a). This is basically the same as #5895 but with a different header.

Modifications

• Added X-Forwarded-For into the HEADERS_TO_IGNORE_IN_LOWER_CASE lists which already skips some of predefined headers

Testing

• Added unit tests that follow the pattern for the other blocked headers

Screenshots (if appropriate)

Types of changes

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

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
  • Historically haven't been able to build due to environment issues
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

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

[millems]

Thanks! Running tests.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[millems]

Our tests are currently blocked on #6397. Sorry about the delay!

[brandondahler]

No problem, rebased on that PR since it looks like it has been merged. Let me know if the way I'm rebasing makes things harder on yall. I know some projects have a specific mechanism they prefer PRs use and others don't.

[millems]

Thanks for your contribution!