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
Response status 415 (unsupported media type) reported as of 416 (which is Range Not Satisfiable), mismatching with superclass constructor parameter HttpStatus.UNSUPPORTED_MEDIA_TYPE
This commit introduces a new readMessageSize(DataBuffer input) private
method, inspired from CodedInputStream#readRawVarint32(int, InputStream)
and adapted for DataBuffer using MessageDecoderFunction fields in
order to support use cases where the message size is split between
distinct chunks.
It also fixes handling of end of streams by using
DataBuffer#readableByteCount instead of -1 which is only relevant with
InputStream.
Issue: SPR-17429
Prior to this commit, when errors happened before the response was
committed, the `Content-Length` response header would be left as is.
This can be problematic since the error can be handled later in the
chain and the response body changed accordingly. For example, Spring
Boot renders error pages in those cases. If the `Content-Length` is set,
HTTP clients can get confused and only consider part of the error
response body.
This commit ensures that any `Content-Length` response header is removed
in case of errors, if the response is not already committed.
This is done at the `AbstractServerHttpResponse` level, since errors can
be handled in multiple places and the response itself is the safest
place to handle this case.
As a consequence, this commit also removes `Content-Length` checks in
`EncoderHttpMessageWriter` since we now consider that we should rely on
the response body we're about to write rather than any previously set
value.
Issue: SPR-17502
Update the ServerHttpRespnose contract to indicate that server specific
sub-classes should fall back on the default status, if a status code
has not been set explicitly.
Issue: SPR-17368
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.
This commit fixes a memory leak in ServerSentEventHttpMessageWriter
that occurs when the input stream contains an error. Test added as well.
Issue: SPR-17419
The fix for SPR-17178 switched from debug to warn level warning for
all sub-classes of AbstractHandlerExceptionResolver where the request
concerned the DefaultHandlerExceptionResolver only.
This commit restores the original DEBUG level logging that was in
AbstractHandlerExceptionResolver from before SPR-17178. In addition
DefaultHandlerExceptionResolver registers a warnLogCategory by default
which enables warn logging and hence fulfilling the original goal
for SPR-17178.
Issue: SPR-17383
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 harmonizes the `HeadersAdapter` implementations across all
supported servers with regards to the `get(Object key)` contract; some
server implementations are not sticking to a `Map`-like contract and
return empty `List` instead of `null` when a header is not present.
This also fixes the `size()` implementations to reflect the number of
header keys, as some implementations consider multiple values for the
same header as different entries.
Issue: SPR-17396
