The alternative is to use a filter but this makes it a little easier
and also guarantees that it will be downstream from all filters
regardless of their order, and therefore the Context will be visible
to all of them.
Closes gh-25710
@ -831,7 +831,7 @@ inline-style, through the built-in `BodyInserters`, as the following example sho
@@ -831,7 +831,7 @@ inline-style, through the built-in `BodyInserters`, as the following example sho
[[webflux-client-filter]]
== Client Filters
== Filters
You can register a client filter (`ExchangeFilterFunction`) through the `WebClient.Builder`
in order to intercept and modify requests, as the following example shows:
@ -887,9 +887,36 @@ a filter for basic authentication through a static factory method:
@@ -887,9 +887,36 @@ a filter for basic authentication through a static factory method:
.build()
----
Filters apply globally to every request. To change a filter's behavior for a specific
request, you can add request attributes to the `ClientRequest` that can then be accessed
by all filters in the chain, as the following example shows:
You can create a new `WebClient` instance by using another as a starting point. This allows
insert or removing filters without affecting the original `WebClient`. Below is an example
that inserts a basic authentication filter at index 0:
@ -912,10 +939,11 @@ by all filters in the chain, as the following example shows:
@@ -912,10 +939,11 @@ by all filters in the chain, as the following example shows:
.Kotlin
----
val client = WebClient.builder()
.filter { request, _ ->
val usr = request.attributes()["myAttribute"];
// ...
}.build()
.filter { request, _ ->
val usr = request.attributes()["myAttribute"];
// ...
}
.build()
client.get().uri("https://example.org/")
.attribute("myAttribute", "...")
@ -923,29 +951,44 @@ by all filters in the chain, as the following example shows:
@@ -923,29 +951,44 @@ by all filters in the chain, as the following example shows:
.awaitBody<Unit>()
----
You can also replicate an existing `WebClient`, insert new filters, or remove already
registered filters. The following example, inserts a basic authentication filter at
index 0:
[[webflux-client-context]]
== Context
<<webflux-client-attributes>> provide a convenient way to pass information to the filter
chain but they only influence the current request. If you want to pass information that
propagates to additional requests that are nested, e.g. via `flatMap`, or executed after,
e.g. via `concatMap`, then you'll need to use the Reactor `Context`.
`WebClient` exposes a method to populate the Reactor `Context` for a given request.
This information is available to filters for the current request and it also propagates
to subsequent requests or other reactive clients participating in the downstream