Mechanism to access request bound objects in WebClient filter in servlet env

[ttddyy]

In servlet environment, when migrating RestTemplate to WebClient, one of the challenges people face is to access http request bound objects within WebClient filters(ExchangeFilterFunction).
I think this is an area currently lacking a support.

For example, SecurityContext, Locale/LocaleContext(LocaleContextHolder), HttpServletRequest(RequestContextHolder) and any values associated to the request(ThreadLocal) cannot easily be retrieved in ExchangeFilterFunction.

I think common solution for this is to use Hooks to populate the values to subscriber's context.

For example, in Spring Security, here defines and registers a hook that populates SecurityContext.
Since this mechanism also populates HttpServletRequest and HttpServletResponse, I leverage it in my exchange filter functions to retrieve request bound values.
I also have similar logic for MDC and LocaleContext.

I think this mechanism should be supported in Spring Framework itself; so that, all downstream libraries and application can leverage it.

For implementation perspective, for example, define a class ReactorContextAttribute which is a map kept in thread local. Then, framework guarantees to populate this map in subscriber's context. So that, users or downstream libraries can simply populate this map in request thread, then retrieves values from the map in subscriber context.
In addition, FrameworkServlet/DispatcherServlet resolved value/context, such as LocaleContext, can be placed in this map to make them accessible in exchange filter functions.

If such mechanism exists, for example, Spring Security can simply add a logic to populate SecurityContext.

I think this is a big missing piece to use WebClient in servlet environment along with supporting MDC.

[rstoyanchev]

@ttddyy, I'm wondering if you've seen the option to add attributes which a filter can then check via ClientRequest:

client.get().uri("https://example.org/")
        .attribute("myAttribute", "...")
        .retrieve()

This can be set up at the WebClient builder level to automate the extraction of ThreadLocal context:

WebClient client = this.builder
		.defaultRequest(spec -> spec.attribute("foo", FooContext.get()))
		.filter(filter)
		.build();

Spring Security uses this and its filter exposes a Consumer that can be used to configure a WebClient builder to extract and pass the information the filter needs.

I believe the mechanism is there for applications to extract and pass exactly what is needed. The mechanics are straight forward and I don't see much value and adding further conventions around that.

We can certainly do better to address this need more specifically in the documentation. There is a mention of the attributes but nothing to address the use case and to tie all of the above together.

[ttddyy]

@rstoyanchev Oh, I wasn't aware of attributes method. Thanks.
Certainly it would be nice to mention ThreadLocal in documentation for attribute method usage.

I have simulated couple of our usecases trying with attributes in servlet environment with WebClient.
This serves most of the cases since I can assign values to attributes from Threadlocal at the time when request is made and on the thread that is making a request.

However, I found one case hard to do with attributes, which is nesting remote calls.
For example, make a first remote call, then based on the response, create another remote call.

Sample code:

ExchangeFilterFunction filter = (request, next) -> {
  log.info("filter map=" + request.attributes());
  return next.exchange(request);
};

WebClient webClient = WebClient.builder().filter(filter).defaultRequest(spec -> {
  spec.attribute("bar", "BAR");
  spec.attribute("tid", Thread.currentThread().getId());
  spec.attribute("tname", Thread.currentThread().getName());
}).build();

webClient.get().uri("http://service1.com")  // first call
    .attribute("foo", "FOO")
    .retrieve()
    .bodyToMono(String.class)
    .flatMap(str -> {
      return webClient.get().uri("http://service2.com")  // second call
          .retrieve()
          .bodyToMono(String.class);
    })
    .subscribeOn(Schedulers.boundedElastic())  // on different thread...
    .block();

When making the first call, attributes tid and tname are main thread, but for the second call, the thread is on elastic thread; so cannot retrieve thread local values that are bound to the caller.

In the real environment, these two calls are service-to-service calls and when I call another service, I need to propagate some values stored in caller's thread local. (very much similar to ServletBearerExchangeFilterFunction in Spring Security)

Workaround can be, when constructing the second call, explicitly add attribute method and pass a value that the filter is looking for. However, it is invasive to application code and would like to handle it in filter or construction of webclient in library.

Currently, I use subscriber context approach as mentioned in the description. (reusing SecurityReactorContextSubscriberRegistrar from Spring Security)

Also, interesting thing is that the ServletOAuth2AuthorizedClientExchangeFilterFunction (pointed in your comment) uses attributes but also it is getting attribute values(request, response, and auth) from subscriber context which is populated by the lifter hook (SecurityReactorContextSubscriberRegistrar).

So, attributes works for single remote call cases, but when multiple calls on different threads are involved, I think above mentioned Hook approach may be in need.

[ttddyy]

If WebClient.Builder could setup its subscriber context(defaultContext method below), maybe this would work.

FooContext.set("main-thread");  // setting to threadlocal

// a filter uses "foo" from subscriber context
ExchangeFilterFunction filter = (request, next) ->
    Mono.subscriberContext()
        .map(context -> (String) context.get("foo"))
        .map(foo -> ClientRequest.from(request).header("foo", foo).build())
        .flatMap(next::exchange);


WebClient webClient = WebClient.builder()
        .filter(filter)
        // populate subscriber context
        .defaultContext(context -> context.hasKey("foo") ? context : context.put("foo", FooContext.get()))
        .build();

webClient.get()
        .uri("http://foo.com")
        .retrieve()
        .bodyToMono(String.class)
        .flatMap(body ->
                webClient.get()
                        .uri("http://bar.com")
                        .retrieve()
                        .bodyToMono(String.class)
        )
        .subscribeOn(Schedulers.boundedElastic())  // on different thread...
        ....
;

// both calls will have header "foo=main-thread"

When nested WebClient is called, the context key "foo" has already populated by outer WebClient, which used the original caller's thread.

Not sure it is even possible, but an idea.