HttpRequest.Builder customizer for Client transports

[Kehrlann]

Provide a way to customize HTTP requests before executing them, for both HttpClientSseClientTransport and HttpClientStreamableHttpTransport.

We introduce AsyncHttpRequestCustomizer, which is the core class that does the heavy lifting. For blocking contexts, we provide a simpler SyncHttpRequestCustomizer API, which ultimately gets wrapped. The details of the implementation in both transports is not relevant (yet) ; we are focused on both customizers and also on the transpots, specifically:

• AsyncHttpRequestCustomizer
• SyncHttpRequestCustomizer
• HttpClientSseClientTransport.Builder#requestCustomizer and HttpClientSseClientTransport.Builder#asyncRequestCustomizer
• HttpClientStreamableHttpTransport.Builder#requestCustomizer and HttpClientStreamableHttpTransport.Builder#asyncRequestCustomizer

Motivation and Context

These are transport-level hooks, to allow users to modify request, e.g. to add security in headers (OAuth2 tokens, API keys, etc).

How Has This Been Tested?

Tested with a Servlet Spring app, using SyncHttpRequestCustomizer.

Breaking Changes

No.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[tzolov]

@Kehrlann I think this would work.
What about the webflux clients. would we need to expose a similar customizer abstractions there as well?

[Kehrlann]

Nice! I’ll tidy up the PR then.

for WebClient-based transport, the WebClient has transformation primitives already (for ex ExchangeFilterFunction), so no need to add an MCP-specific customizer.

[tzolov]

Thanks @Kehrlann