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
Juergen Hoeller
Rossen Stoyanchev
sdeleuze
Violeta Georgieva
anton_bondarenko
Arjen Poutsma