DefaultUriBuilderFactory now uses EncodingMode.TEMPLATE_AND_VALUES by
default. However the RestTemplate explicitly sets it to the previous
setting EncodingMode.URI_COMPONENTS, so this affects mainly the
WebClient and any direct use of DefaultUriBuilderFactory to configure
either the RestTemplate or the WebClient.
Issue: SPR-17039
The ability to request to encode before `build()`, and more importantly
before expanding, allows stricter encoding to be applied to URI vars
and consequently to neutralize the effect of characters with reserved
meaning in a URI.
Issue: SPR-17039
Introduces a configure method pattern for Supplier-style configuration and a common SingletonSupplier decorator for method reference suppliers. Also declares jcache.config and jcache.interceptor for non-null conventions.
Issue: SPR-17021
This commit removes the session threshold check added recently which
is not effective since maxIdleTime is usually much longer than the
frequency of checks. The lazy triggering of expiration checks during
create or retreive are simple and the most effective
This commit also adds a maxSessions limit on the total number of
sessions that can be created at any one time, a getSessions method
for management purposes, and a removeExpiredSessions public API
for manual triggering of expiration checks.
Issue: SPR-17020, SPR-16713
Prior to this commit, `WebClient` would throw `IllegalArgumentException`
when receiving an HTTP response with an unknown HTTP status code.
This commit is a follow up of SPR-16748 (supporting non-standard HTTP
status codes on the reactive `ClientHttpResponse`), and is mirroring
SPR-15978 (supporting non-standard HTTP status codes in `RestTemplate`).
With this change, `WebClient` now tolerates unknown status codes in some
cases, while not offering that choice as a first class citizen:
`HttpStatus` is still the preferred way to deal with HTTP status codes.
Here's how `WebClient` will behave when fetching the full response:
```
// Given a remote endpoint returning a "123" HTTP status code
Mono<ClientResponse> result = this.webClient.get()
.uri("/status/123")
.exchange();
// will still throw an IllegalArgumentException
HttpStatus status = result.block().statusCode();
// is safe and will return 123
int statusCode = result.block().rawStatusCode();
```
Resolving directly the response body with `retrieve()` is different.
```
// will send an error signal with a UnknownHttpStatusCodeException
Mono<String> result = this.webClient.get()
.uri("/status/123")
.retrieve()
.bodyToMono(String.class);
```
In general, `WebClient` will provide high-level support
for well-known HTTP status codes, like error handling with
`WebClient.ResponseSpec#onStatus`.
For such support with unknown status codes, it is better to rely
on lower level constructs such as `ExchangeFilterFunction`.
Issue: SPR-16819
1. Add session count threshold as am extra pre-condition.
2. Check pre-conditions for expiration checks on every request.
Effectively an upper bound on how many sessions can be created before
expiration checks are performed.
Issue: SPR-17020
This commit restricts the support of `"Content-Range"` when returning
`Resource` instances from Controllers - now only "HTTP 200 OK" responses
will be considered, as Controllers might want to handle content range
themselves.
Issue: SPR-16921
1. Use special category prefix "spring-web.reactivestreams" for logging
of reactive streams signals in spring-web, since those are quite
verbose would fill the logs at TRACE.
2. Add and use loggers in request and websocket session implementations
separate from reactive streams bridge for regular TRACE logging.
3. Improve log messages and add where missing (e.g. for Reactor)
Issue: SPR-16898
Rossen Stoyanchev
Juergen Hoeller
Stephane Nicoll
Brian Clozel
Guilherme Alan Ritter
xiexed
zilong6
Arjen Poutsma
stsypanov
Sam Brannen