This commit improves the message for HttpStatusCodeException so that it
defaults to the HttpStatus reason phrase if a status text is not
provided.
This commit also fixes SimpleClientHttpResponse so that it does not
return null for getStatusText().
Fixed#22162
Commit #93b7a4 added support for pre-configuring URI variables at the
UriComponentsBuilder level, and also changed toUriString to encode
template and URI variables separately. However this went a bit too far
causing side effects for URLs with curly braces that don't represent
URI variables.
This commit restores the original toUriString behavior which is to
encode template and URI variables sepraately only if URI variables have
been pre-configured.
Issue: SPR-17630
Aalto's InputFactoryImpl already disables loading of external entities
by default (property "javax.xml.stream.isSupportingExternalEntities").
This commit goes further by applying the same defensive measures as we
do elsewhere for XMLInputFactory, which disables DTD completely.
Arguably there is no good reason to enable that by default in WebFlux.
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
This commit makes TomcatServerHttpRequest aware of
HttpServletRequestWrappers, and TomcatServerHttpResponse aware of
HttpServletResponseWrappers.
Issue: SPR-17611
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