Affects: Spring Framework 6.1 We have use cases where we are a client to an API that for every request requires header population specific to a particular client of ours. For this use case, ClientRequest.attribute is useful to pass this information up the filter chain for an ExchangeFilterFunction to use. The filter function would determine based on the customer information supplied the elements required on the header.
It would be very useful to have similar functionality in HttpExchange interfaces so that some request context data could be passed up the filter or interceptor chain and be available for a filter function or request interceptor to reference and process uniquely for that request. That way, this header population could be accomplished automatically from an isolated class without the need for a developer to use chained WebClient calls to call the APIs that require these headers.
Example of the type of functionality that this Issue is requesting:
@HttpExchange
interface CustomerApi {
@PostExchange("/customers")
void createCustomer(@RequestBody CreateCustomerRequest createCustomerRequest, @ContextAttribute UUID organizationId);
}
@Component
class OrganizationRequestFilter implements ExchangeFilterFunction {
private final OrganizationService organizationService;
...
@Override
public Mono<ClientResponse> filter(ClientRequest request, ExchangeFunction next) {
Organization org = organizationService.find(request.attribute("organizationId").orElseThrow());
ClientRequest newRequest =
ClientRequest.from(request).headers(headers -> addOrgCredentials(headers, org)).build();
return next.exchange(newRequest);
}
private void addOrgCredentials(HttpHeaders httpHeaders, Organization org) {
...
httpHeaders.set("Authorization", buildHmac(org));
}
}
Comment From: rstoyanchev
@JRBail, this is already possible through @RequestAttribute
like for example in this test. However, I see that it's not actually listed in the documentation for supported HTTP Interface Method Parameters.
I'll change this into a documentation update.
Comment From: rstoyanchev
This is actually already addressed for the upcoming 6.1.4 with #32231.