Prior to this commit, patterns like `"/path/**/other"` would be treated
as `"/path/*/other"` (single wildcard, i.e. matching zero to many chars
within a path segment). This will not match multiple segments, as
expected by `AntPathMatcher` users or by `PathPatternParser` users when
in patterns like `"/resource/**"`.
This commit now rejects patterns like `"/path/**/other"` as invalid.
This behavior was previously warned against since gh-24958.
Closes gh-24952
When mutating a ServerHttpRequest or ClientResponse, the respective
builders no longer access cookies automatically which causes them to
be parsed and does so only if necessary. Likewise re-applying the
read-only HttpHeaders wrapper is avoided.
See gh-24680
This commit introduces a test suite for ClientHttpConnector
implementations, as well as fixes that resolve issues identified by
these tests.
Closes gh-24941
As of gh-24952, `PathPatternParser` will strictly reject patterns with
`"**"` in the middle of them. `"**"` is only allowed at the end of the
pattern for matching multiple path segments until the end of the path.
Currently, if `"**"` is used in the middle of a pattern it will be
considered as a single `"*"` instead. Rejecting such cases should
clarify the situation.
This commit prepares for that upcoming change and:
* logs a warning message if such a case is used by an application
* expands the MVC and WebFlux documentation about URI matching in
general
Closes gh-24958
Spring Framework 5.2.2 introduced a regression in
DefaultResponseErrorHandler.handleError(ClientHttpResponse)
Specifically, for use cases where the InputStream had already been
consumed by the first invocation of getResponseBody(), the second
invocation of getResponseBody() resulted in the response body being
absent in the created UnknownHttpStatusCodeException.
This commit fixes this by invoking getResponseBody() only once in
DefaultResponseErrorHandler.handleError(ClientHttpReponse) in order to
reuse the retrieved response body for creating the exception message
and as a separate argument to the UnknownHttpStatusCodeException
constructor.
Closes gh-24595
This commit adds two new properties to the `ReactorResourceFactory`.
This allows to configure the quiet and timeout periods when shutting
down Reactor resources. While we'll retain Reactor Netty's default for
production use, this option is useful for tests and developement
environments when developers want to avoid long waiting times when
shutting down resources.
Fixes gh-24538
Jackson's asynchronous parser does not support any encoding except UTF-8
(or ASCII). This commit converts non-UTF-8/ASCII encoded JSON to UTF-8.
Closes gh-24489
This commit makes the Jackson2Tokenizer enable
TokenBuffer.forceUseOfBigDecimal if the element type given to the
Decoder is BigDecimal. Previous to this commit, values would be
converted to floats.
Closes gh-24479
After this commit, Jackson2Tokenizer honours ObjectMapper's
DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS feature when creating
TokenBuffers.
Closes gh-24479
ContentNegotiationManagerFactoryBean now ensures that
ContentNegotiationManager contains the MediaType mappings even if the
path extension and the parameter strategies are off.
There are also minor fixes to ensure the media type mappings in
ContentNegotiationManagerFactoryBean aren't polluted when mapping keys
are not lowercase, and likewise MappingMediaTypeFileExtensionResolver
filters out duplicates in the list of all file extensions.
See gh-24179
Before this commit, the AbstractJackson2Encoder instantiated a
ObjectWriter per value. This is not an issue for single values or
non-streaming scenarios (which effectively are the same, because in the
latter values are collected into a list until offered to Jackson).
However, this does create a problem for SMILE, because it allows for
shared references that do not match up when writing each value with a
new ObjectWriter, resulting in errors parsing the result.
This commit uses Jackson's SequenceWriter for streaming scenarios,
allowing Jackson to reuse the same context for writing multiple values,
fixing the issue described above.
Closes gh-24198
Prior to this commit, when WebFlux handlers added `"Content-*"` response
headers and an error happened while handling the request, all those
headers would not be cleared from the response before error handling.
This commit clears those headers from the response in two places:
* when invoking the handler and adapting the response
* when writing the response body
Not removing those headers might break HTTP clients since they're given
wrong information about how to interpret the HTTP response body: the
error response body might be very different from the original one.
Fixes gh-24238
