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
This allows us to confirm 0.7.3 fixes and run tests against the latest
ahead of an upgrade to Reactor Netty 0.8 snapshots.
The fix for #231 and #240 are confirmed but unfortunately test case for
With this commit, the default content-type defined by the
view (usually "text/html;charset=UTF-8" defined in AbstractView)
is used if any, when none is defined in the response headers.
Issue: SPR-16247
If the response is set and we can't change the status through
ServerHttpResponse any more, allow the error signal to propagate and
let the individual server adapters handle it. Ultimately that should
result in closing the connection.
On Servlet containers, we check one last time if the response is
committed (we may not have filled the buffer). If not then save
the exception as a request attribute, dispatch, and re-throw it on the
container thread.
On Undertow access the connection and close it.
On Netty just let the error through to Reactor Netty.
Issue: SPR-16051
From #9a894a we began using the content-type from the ResponseEntity
but cross-checking it still against the requested content type.
Arguably there isn't any purpose in cross-checking. The only possible
outcomes are: a) it's compatible or b) it's not, which would result in
406 (NOT_ACCEPTABLE). As we've been given explicitly the media type to
use, it makes little sense to send 406, ignoring the wish to use that
content type.
Issue: SPR-16251
Before this commit, the return value from write was interpreted as the
data being fully written and ready to be released via releaseData().
This is not true for WebSocketSession implementations where a true
return value simply means the message was sent with the full payload
but releas is not appropriate until a send confirmation.
Technically not an issue since WebSocketSession's extending this do
not use pooled buffers. Nevertheless this commit refines the semantics
of write, removes the releaseData() method, and makes sub-classes
responsible for releasing the buffer when fully written (and they
know best when that is). As a bonus currentData is now private.
Issue: SPR-16207
After this commit, Tomcat and Undertow WebSocketSession imlpementations
start out in suspended mode and wait for demand.
The JettyWebSocketSession is capable of suspending but it doesn't seem
to work if invoked before any messages are received. That may become an
issue if there is a case where no demand appears long enough for more
messages to accumulate than we can hold.
UnderowServerHttpRequest would ideally also start in suspended mode but
that also doesn't work. It is not an issue in this case since we can
ignore the read notifications.
Servlet API requires a proactive check before it calls you back so
there is no need to suspend.
Issue: SPR-16207
This commit turns suspendReading() into a readingPaused() notification
that is invoked after a succession of reads stops because there is no
more demand. Sub-classes can use this notification to suspend, if that
applies to them.
Most importantly the notification is guaranteed not to overlap with
checkOnDataAvailable() which means that suspend does not need to be
atomic and guarded against resume. The two can and do compete all the
time when reading ends with no demand, and a request for demand arrives
concurrently.
Issue: SPR-16207
Access-Control-Allow-Credentials CORS header, used to
allow cookies with CORS requests, is not set to true
anymore by default when enabling CORS with
@CrossOrigin or global CORS configuration in order to
provide a more secured default CORS configuration.
The related allowCredentials property now requires to
be set to true explicitly in order to support cookies
with CORS requests.
Issue: SPR-16130
This commit adds
AbstractMessageReaderArgumentResolver#readBody and
AbstractMessageWriterResultHandler#writeBody variants
which allow to pass the actual MethodParameter in order
to perform proper annotation-based hint resolution with
nested generics, for example with HttpEntity.
Issue: SPR-16098
Practically no changes to RxNetty for a year and efforts underway to
rebuild 0.6.x based on a current Reactor Netty base.
Aside from the extra time to run integration tests having two
Netty-based servers can also cause false alarms such as ByteBuf leaks
related to RxNetty.
This commit introduces a new AbstractReactiveWebInitializer in
spring-web that relies on WebHttpHandlerBuilder to detect request
processing infrastructure beans from an ApplicationContext.
This eliminates the need to create a DispatcherHandler, since it is
expected to be a Spring bean, and as a result the initializers in
spring-webflux have been deprecated.
Issue: SPR-16144
FromHttpMessageWriter and MultipartHttpMessageWriter both support
MultiValueMap except the former supports String values only. This
presents an issue since either full generic type information must be
provided, which is cumbersome on the client side, or if left out there
is no good way to order the writers to make a proper decision.
This commit:
- refines the canWrite behavior of to not a
accept MultiValueMap without proper generic information unless the
MediaType is explicitly set providing a strong hint.
- modifies MultipartHttpMessageWriter to be configured with a
FormHttpMessageWriter so it can write both plan and multipart data with
the ability to properly differentiate based on actual map values.
Issue: SPR-16131
This commit exposes the ClientRequest's URL and HttpMethod fields via a
setter, so that they can be changed more easily in a request that was
created via ClientRequest.from(ClientRequest).
Issue: SPR-16093
Before this commit, when adding filters to a builder obtained via
`WebClient.mutate()`, the filters were added both to the original client
as well as the mutated builder. This commit fixes that.
Issue: SPR-16059
Prior to this commit, the `ResourceWebHandler` would itself handle the
response with an HTTP 404 in many cases, including a missing static
resource.
This does not give a chance to `WebExceptionHandler` instances to handle
that error and, for example, display an error page.
See spring-projects/spring-boot#8625
Issue: SPR-16023
Concrete server and client, reactive request and response
implementations should not have to be accessed outside their package.
They could be seen as private to their HttpHandler adapters and
ClientHttpConnector's respectively.
The one exception, WebSocket upgrades in spring-webflux, is an internal
framework use case, accommodated via downcast + accessors in the
abstract base classes.
Prior to this commit, the `WebClient` always throws a `ClassCastException`
when an error occurs in `bodyToMono(ParameterizedTypeReference)``, and
not the expected exception, as set up by `onStatus`
Issue: SPR-16025
igor-suhorukov
Rossen Stoyanchev
Arjen Poutsma
Juergen Hoeller
sdeleuze
Violeta Georgieva
anton_bondarenko
Brian Clozel