Prior to this commit, the negotiated content-type during the request
mapping phase would be kept as the response content-type header; this
information is used when rendering the error response and prevents a new
round of content negotiation to choose the media type that fits best.
This commit removes the response content type information at the
beginning of the error handling phase.
Fixes gh-22452
This commit is the first part of a more complete Coroutines
support coming in Spring Framework 5.2. It introduces suspendable
Kotlin extensions for Mono based methods in WebFlux classes like
WebClient, ServerRequest, ServerResponse as well as a Coroutines
router usable via `coRouter { }`.
Coroutines extensions use `await` prefix or `AndAwait` suffix,
and most are using names close to their Reactive counterparts,
except `exchange` in `WebClient.RequestHeadersSpec`
which translates to `awaitResponse`.
Upcoming expected changes are:
- Leverage `Dispatchers.Unconfined` (Kotlin/kotlinx.coroutines#972)
- Expose extensions for `Flux` based API (Kotlin/kotlinx.coroutines#254)
- Introduce interop with `CoroutineContext` (Kotlin/kotlinx.coroutines#284)
- Support Coroutines in `ReactiveAdapterRegistry`
- Support Coroutines for WebFlux annotated controllers
- Fix return type of Kotlin suspending functions (gh-21058)
See gh-19975
Prior to this commit, the `ExchangeFilterFunction` instances configured
on a `WebClient` instance would be executed as soon as the `exchange`
method would be called. This behavior is not consistent with the server
side and can confuse filter developers as they'd need to manually
`Mono.defer()` their implementations if they want to record metrics.
This commit defers all `ExchangeFilterFunction` processing at
subscription time.
Fixes gh-22375
Prior to this commit, profiling sessions would show that using
`java.util.stream.Stream` in some hot code paths creates significant
garbage.
Where streams aren't really required, this commit turns those snippets
into imperative logic because those are likely to be called once or
multiple times per request.
Closes gh-22341
Prior to this commit, Spring WebFlux function would let
`DecodingException` thrown by codecs bubble up to the web handler level.
Since this exception is not handled by default there, the response would
be turned into a HTTP 500 status.
In the annotation model, `ArgumentResolver` implementations wrap this
exception with a `ServerWebInputException`, which itself extends
`ResponseStatusException`. The latter is supported by the error handling
infrastructure as a HTTP 400 response.
This commit ensures that `DecodingException` instances are properly
wrapped in `ServerWebInputException` at the `ServerRequest` level
directly, thus supporting all setup modes ("standalone" and through the
`DispatcherHandler`).
Fixes#22290
Typically a straight up equals as well as Collections#contains
checks for MediaType.ALL is susceptible to the presence of
media type parameters.
This commits adds equalsTypeAndSubtype as well as an
isPresentIn(Collection<MimeType>) methods to MimeType to faciliate
with checks for MediaType.ALL.
Issue: SPR-17550
Prior to this commit, one could write a `CharSequence` to an existing
`DataBuffer` instance by turning it into a byte array or `ByteBuffer`
first. This had the following disadvantages:
1. Memory allocation was not efficient (not leveraging pooled memory
when available)
2. Dealing with `CharsetEncoder` is not always easy
3. `DataBuffer` implementations, like `NettyDataBuffer` can use
optimized implementations in some cases
This commit adds a new `DataBuffer#write(CharSequence, Charset)` method
for those cases and also an `ensureCapacity` method useful for checking
that the current buffer has enough capacity to write to it..
Issue: SPR-17558
Commit #c187cb2 introduced proactive rejection of multiple subscribers
in ReactorClientHttpResponse, instead of hanging indefinitely as per
https://github.com/reactor/reactor-netty/issues/503.
However FluxReceive also rejects subsequent subscribers if the response
is consumed fully, as opposed to being canceled, e.g. as with
bodyToMono(Void.class). In that case, a subsequent subscriber causes
two competing error signals to be sent, and one gets dropped and
logged by reactor-core.
This fix ensures that a rejection is raised in
ReactorClientHttpResponse only after a cancel() was detected.
Issue: SPR-17564
This commit makes the 3 existing InvocableHandlerMethod types more
consistent and comparable with each other.
1. Use of consistent method names and method order.
2. Consistent error formatting.
3. Explicit for loops for resolving argument values in webflux variant
because that makes it more readable, creates less garabage, and it's
the only way to bring consistency since the other two variants cannot
throw exceptions inside Optional lambdas (vs webflux variant which can
wrap it in a Mono).
4. Use package private HandlerMethodArgumentComposite in webflux
variant in order to pick up the resolver argument caching that the
other two variants have.
5. Polish tests.
6. Add missing tests for messaging variant.
Prior to this commit, no `ResourceUrlProvider` was configured
in WebFlux (no bean was contributed by the WebFlux infrastructure).
Also, several `ResourceTransformer` instances that extend the
`ResourceTransformerSupport` base class need a `ResourceUrlProvider`
to resolve absolute URLs when rewriting resource URLs. At this point,
no `ResourceUrlProvider` was configured and they could only resolve
relative URLs.
This commit contributes a new `ResourceUrlProvider` to the WebFlux
configuration; this bean can be reused by the WebFlux infrastructure and
application code.
This also automatically configure this shared `ResourceUrlProvider`
instance on the resource chain where needed.
Issue: SPR-17433
Prior to this commit, `ResourceTransformerSupport.toAbsolutePath`
would call `StringUtils.applyRelativePath` in all cases. But this
implementation is prepending the given path even if the relative path
starts with `"/"`.
This commit skips the entire operation if the given path is absolute,
i.e. it starts with `"/"`.
Issue: SPR-17432
Review and update Servlet and Undertow adapters to release any data
buffers they be holding on to at the time of error or cancellation.
Also remove onDiscard hooks from Reactor and Undertow request body.
For Reactor we expect it to be handled. For Undertow there isn't
any Reactor Core upstream for the callback to be useful.
Issue: SPR-17410
This commit changes the attributes stored under
RouterFunctions.MATCHING_PATTERN_ATTRIBUTE and
HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE from a String to a
PathPattern, similar to what annotated controllers set.
Issue: SPR-17395
Several benchmarks underlined a few hotspots for CPU and GC pressure in
the Spring Framework codebase:
1. `org.springframework.util.MimeType.<init>(String, String, Map)`
2. `org.springframework.util.LinkedCaseInsensitiveMap.convertKey(String)`
Both are linked with HTTP request headers parsing and response headers
writin during the exchange processing phase.
1) is linked to repeated calls to `HttpHeaders.getContentType`
within a single request handling. The media type parsing operation
is expensive and the result doesn't change between calls, since
the request headers are immutable at that point.
This commit improves this by caching the parsed `MediaType` for the
`"Content-Type"` request header in the `ReadOnlyHttpHeaders` class.
This change is available for both Spring MVC and Spring WebFlux.
2) is linked to insertions/lookups in the `LinkedCaseInsensitiveMap`,
which is the data structure behind `HttpHeaders`.
Those operations are creating a lot of garbage (including a lot of
`String` created by `toLowerCase`). We could choose a more efficient
data structure for storing HTTP headers data.
As a first step, this commit is focusing on Spring WebFlux and
introduces `MultiValueMap` implementations mapped by native HTTP headers
for the following servers: Tomcat, Jetty, Netty and Undertow.
Such implementations avoid unnecessary copying of the headers
and leverages as much as possible optimized operations provided by the
native implementations.
This change has a few consequences:
* `HttpHeaders` can now wrap a `MultiValueMap` directly
* The default constructor of `HttpHeaders` is still backed by a
`LinkedCaseInsensitiveMap`
* The HTTP request headers for the websocket HTTP handshake now need to
be cloned, because native headers are likely to be pooled/recycled by
the server implementation, hence gone when the initial HTTP exchange is
done
Issue: SPR-17250
In order to be able to leverage WebFlux configuration in a functional
way, WebHttpHandlerBuilder and RouterFunctionMapping should leverage
new ObjectProvider capabilities to get a sorted list of beans by type
instead of using autowired containers.
Issue: SPR-17327
Switch to using the sendClose method available since Reactor Netty 0.8
vs explicitly sending a CloseWebSocketFrame.
Related to SPR-17306, but does not address the root cause.
1. Helper method to eliminate duplication in formatting (de-)serialized
values for logging introduced with prior commit #e62298.
2. Helper method for TRACE vs DEBUG logging with different details.
Issue: SPR-17254
This commit handles "empty" cases for `ResponseEntity` controller
handler return types when wrapped with a `java.util.Optional` in Spring
MVC or a single `Publisher` like `Mono`.
Given the following example for Spring MVC:
```
@GetMapping("/user")
public Optional<ResponseEntity<User>> fetchUser() {
Optional<User> user = //...
return user.map(ResponseEntity::ok);
}
```
If the resulting `Optional` is empty, Spring MVC will infer a
`ResponseEntity` with an empty body and a 404 HTTP response status.
The same reasoning is applied to Spring WebFlux with Publisher types:
```
@GetMapping("/user")
public Mono<ResponseEntity<User>> fetchUser() {
Mono<User> user = //...
return user.map(ResponseEntity::ok);
}
```
This feature is only valid for `HttpEntity` return types and does not
apply to `@ResponseBody` controller handlers.
Issue: SPR-13281
This commit allows to specify a custom CorsConfigurationSource
in AbstractHandlerMapping (both Servlet and Reactive variants).
AbstractHandlerMapping#getCorsConfigurations method is now
deprecated.
Issue: SPR-17067
1. Update ExchangeFilterFunctions to delegate internally to
HttpHeaders.setBasicAuth(user, password).
2. Remove deprecation from
ExchangeFilterFunctions.basicAuthentication(String user, String password)
It is still useful as a filter to insert the header.
3. Update deprecation notes.
Issue: SPR-17099
Forwarded headers are now processed before ServerWebExchange is created
through ForwardedHeaderTransformer which has the same logic as the
ForwardedHeaderFilter but works on the request only.
ForwardedHeaderFilter is deprecated as of 5.1 but if registered it is
removed from the list of filters and ForwardedHeaderTransformer is used
instead.
Issue: SPR-17072
Empty Maps are preferably initialized without capacity (not initializing them at all or lazily initializing with default capacity when needed).
Issue: SPR-17105
This commit introduces Protobuf support in WebFlux via dedicated
codecs.
Flux<Message> are serialized/deserialized using delimited Protobuf
messages with the size of each message specified before the message
itself. In that case, a "delimited=true" parameter is added to the
content type.
Mono<Message> are expected to use regular Protobuf message
format (without the size prepended before the message).
Related HttpMessageReader/Writer are automatically registered when the
"com.google.protobuf:protobuf-java" library is detected in the classpath,
and can be customized easily if needed via CodecConfigurer, for example
to specify protocol extensions via the ExtensionRegistry based
constructors.
Both "application/x-protobuf" and "application/octet-stream" mime types
are supported.
Issue: SPR-15776
Prior to this commit, controller handlers (regular and exception
handlers as well) would not overwrite existing HTTP response headers on
the exchange. This would lead to situations where Content-Type values
set during the initial handling phase would not be overwritten when
handling an error later on.
This commit aligns the implementation of that result handler on the
Spring MVC one in that regard.
Issue: SPR-17082
Prior to this commit, the `DefaultClientResponse` implementation would
handle HTTP client cases where the server response body would need to be
consumed (pooled resources need to be released) and the body publisher
cancelled right away. This is done to avoid reading the whole response
body and returning the connection to the pool, now that this connection
cannot be reused.
This was done already when the `WebClient` is asked for a `Void` type
for the response body.
SPR-17054 brought a new case for that: whenever no message reader is
able to decode the response body, an `UnsupportedMediaTypeException`
error signal is sent. Prior to this commit, the response body would not
be consumed and cancelled for that case.
This commit refactors all those cases from the `DefaultClientResponse`
directly into the `BodyExtractors`, since most of the logic and
knowledge for that belongs there. We only need to only apply this
behavior when the HTTP client is involved, as the server does not want
this to happen.
Issue: SPR-17054
Given "/{foo}" and "/a=42;c=b", previously that would be treated as a
sequence of matrix vars with an empty path variable. After the change
the path variable "foo" is "a=42".
This should be ok for backawards compatibility since it's unlikely for
anything to rely on an empty path variable.
Issue: SPR-11897
Leverage https://github.com/jetty-project/jetty-reactive-httpclient
to add support for Jetty in WebClient via JettyClientHttpConnector.
Implemented with buffer copy instead of optimized buffer wrapping
because the latter hangs since Callback#succeeded doesn't allow
releasing the buffer and requesting more data at different times
(required for Mono<DataBuffer> for example).
See https://github.com/eclipse/jetty.project/issues/2429.
Issue: SPR-15092
Prior to this commit, resolving an argument for a WebFlux controller
that's missing from the request and not required by the handler would
throw a NullPointerException in some cases.
This involves the conversion of the parameter (a `String` parameter type
might not trigger this behavior) and sending a `null` within a reactive
stream, which is illegal per the RS spec.
We now rely on a `Mono.justOrEmpty()` to handle those specific cases.
Issue: SPR-17050
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. 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
Hiding it (at AbstractServerHttpRequest) complicates matters since
requests are often mutated and decorated, plus it's also possible to
implement the interface directly (we've one, albeit corner case).
Issue: SPR-16966
1. Eliminate WebSocketClientSupport base class whose main value was
to provide logging but those methods get in the way of inserting a
log prefix.
2. Remove checks and synchronization in lifecycle methods of Jetty
client since underlying Jetty client already has that.
This commit introduces RouterFunctions.Builder, a new way to build
router functions that does not require static imports, thus being more
discoverable and convenient.
Issue: SPR-16953
Polish a few issue identified when adding checkstyle to the
build. Although checkstyle is not enforcing rules on tests,
these are a few minor changes that are still worth making.
Issue: SPR-16968
Reorganize imports to ensure consistent ordering. This commit also
expands any `.*` static imports in favor of using fully-qualified
method references.
Issue: SPR-16968
Update all classes so that inner classes are always last. Also
ensure that utility classes are always final and have a private
constructor and make exceptions final whenever possible.
Issue: SPR-16968
In SPR-16892, the `EncoderHttpMessageWriter` has been improved to write
`"Content-Length"` HTTP response headers if the response body is of type
`Mono` (i.e. the actual content length is easily accessible without
buffering a possibly large response body). That change was relying on
the fact that the server side is using a `ChannelSendOperator` to delay
the writing of the body until the first signal is received.
This strategy is not effective on the client side, since no such channel
operator is used for `WebClient`. This commit improves
`EncoderHttpMessageWriter` and delays, for `Mono` HTTP message bodies
only, the writing of the body so that we can write the
`"Content-Length"` header information once we've got the body resolved.
Issue: SPR-16949
Prior to this commit, the generated POMs for Spring Framework modules
would contain unneeded/harmful information from the Spring Framework
build:
1. The BOM imports applied to each module by the dependency
management plugin, for example for Netty or Reactor Netty.
Spring should not export that opinion to its POMs.
2. The exclusion of "org.slf4:jcl-over-slf4j" from *all* dependencies,
which made the POMs much larger than necessary and suggested to
developers that they should exclude it as well when using all those
listed dependencies. In fact, only Apache Tiles currently brings that
transitively.
This commit removes that information from the POMs.
The dependencyManagement Gradle plugin is disabled for POM generation
and we manually resolve the dependency versions during the generation
phase.
The Gradle build is streamlined to exclude "org.slf4:jcl-over-slf4j"
only when necessary.
Issue: SPR-16893
The key in CachingResourceResolver now includes the "Accept-Encoding"
request header cleaned to exclude "*", "identity", and parameters, and
also sorted alphabetically.
For encoded resources the response now includes a response header with
"Vary: Accept-Encoding".
Issue: SPR-16381
The new EncodedResourceResolver is a generalized version of
GzipResourceResolver that can be configured to support different
content codings, by "br" and "gzip".
GzipResourceResolver is now deprecated.
Issue: SPR-16381
This commit makes it possible to pass attributes from the WebSession of
a handshake request to the WebSocketSession, by configuring a
Predicate<String> on HandshakeWebSocketService.
Issue: SPR-16212
This commit removes all places where forwarded headers are checked
implicitly, on an ad-hoc basis.
ForwardedHeaderFilter is expected to be used instead providing
centralized control over using or discarding such headers.
Issue: SPR-16668
This commit exposes the resource lookup function used by
`RouterFunctions.resources(String, Resource)`, so that it can be
composed upon.
Issue: SPR-16788
This commit introduces support for creating a new `ServerRequest` from
an existing instance. This is especially useful when filtering requests
in a HandlerFilterFunction.
Issue: SPR-16707
ServerSentEventHttpMessageReader had logic to split on new lines
and buffer until an empty new line (start of a new event). To account
for random data chunking, it later re-assembled the lines for each
event and split again on new lines. However bufferUntil was still
unreliable a chunk may contain nothing but a newline, which doesn't
necessarily mean an empty newline in the overall SSE stream.
This commit simplifies the above by delegating the splitting of the
stream along newlines to StringDecoder.
Issue: SPR-16744
This breaks the package dependency cycle between web.server/web.method and makes ServerErrorException more generally applicable. Includes deprecation of the plain reason constructor variant, in favor of providing a Method or MethodParameter context (which MatrixVariableMethodArgumentResolver does now).
Consistently return "*/*" if no media types were requested rather than
an empty list. Existing code has to check for both in any case to see
if nothing was requested.
Issue: SPR-16624
The web.server package is quite low-level and should not depend on web.bind in order to avoid a dependency cycle. Extracting the introspection of the ResponseStatus annotation into a WebFlux-level subclass resolves the cycle.
Issue: SPR-16567
After this commit the use of interval in tests is combined with
take(n).onBackpressureBuffer(n) to ensure emissions don't fail if the
fixed rate is exceeded (e.g. on slow CI server).
Tests that verify N number of items followed by verifyOnComplete()
should set the number of emissions to N.
Tests that verify N number of items followed by thenCancel() should
set the number of buffered to an arbitrary number greater than N.
This commit adds these 2 Vary headers in addition to the existing
Origin one to avoid caching of Access-Control-Request-Method and
Access-Control-Request-Headers headers which can be an issue
when allowed methods or headers are unbounded and only the
requested method or headers are returned in the response.
Issue: SPR-16413
The commit brings following changes:
- Move getDecodableMimeTypes() to AbstractJackson2Decoder
- Move getEncodableMimeTypes() to AbstractJackson2Encoder
- Add support for application/stream+x-jackson-smile
- Avoid streaming line separator when Smile encoder is used
- Use double null token in Jackson2Tokenizer to identify documents
Issue: SPR-16151
This commit checks the Etag/LastModified headers on the incoming
request, and sets a 304 Not Modified status with no body when they
match, by delegating to ServerWebExchange.checkNotModified.
Issue: SPR-16348
Use DataBufferUtils.compose instead of writeAggregator to combine
multiple data buffers into one, as the write aggregator would not work
when the initial data buffer did not have enough capacity to contain
all subsequent buffers.
Removed writeAggregator, as it is no longer needed.
Issue: SPR-16365
Clarify what PathPatternParser is used for which is CORS checks in the
very least. Some sub-classes will also use it for request mapping but
not all (e.g. RouterFunctionMapping). Hence the need to be more
explicit.
@EnableWebFlux bootstraps both annotated controllers and functional
endpoints, so we need to be more explicit about which parts of the
configuration apply to which.
Issue: SPR-16360
Since type erasure can be fixed only when using
ParameterizedTypeReference based Java methods, RestOperations and
WebFlux API documentation should be updated to specify which extensions
are subject to type erasure, and which are not.
Issue: SPR-16273
Sebastien Deleuze
stsypanov
Arjen Poutsma
Rossen Stoyanchev
Usman
Juergen Hoeller
Johnny Lim
Brian Clozel
Ryan Scheidter
Kamil Szymanski
Hanope
Vikash Tiwari
dmrachkovskyi
Sam Brannen
xiexed
Phillip Webb
Napster
Violeta Georgieva
Stephane Nicoll
Johannes Edmeier
nkjackzhang
igor-suhorukov
Christoph Dreis
Andy Wilkinson