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
