In addition to the updates from PR#1297 this commit adds an integration
test and fixes for the resulting failures with RxNetty, Reactor Netty,
and Undertow.
Also replaced use of URLDecoder which is not for decoding URIs with use
of UriUtils for decoding query parameters.
Issue: SPR-15140
%-encoded strings were injected undecoded into @RequestParam variables,
which does not coincide with spring-webmvc behaviour. This commit
fixes AbstractServerHttpRequest.getQueryParams() to correctly return
decoded name-value pairs.
Issue: SPR-15140
MockServerHttpRequest and MockServerHttpResponse now extend the same
abstract base classes that server-specific implementations do and
therefore approximate their behavior more closely.
As an immediate consequence MockServerHttpRequest is read-only after
it is created. Instead it now exposes static builder methods similar
to those found in RequestEntity. This enforces more strictness as well
as recycling of requests in tests and provides nicer builder methods.
To simplify tests DefaultServerWebExchange now offers a constructor
with just a request and response, and automatically creating a
DefaultWebSessionManager.
The spring-test module now also contains client-side reactive mock
request and response implementations. The mock client request extends
the same AbstractClientHttpRequest as client-specific implementations
do. There is no abstract base class for client responses.
Issue: SPR-14590
Prior to this commit, the `ResourceHttpMessageConverter` would support
converting from an `HttpInputMessage` to a `InputStreamResource`. This
is valid when reading resources on the server side, but it's not
compatible with the way `RestTemplate` works.
The API exposed by `RestOperations` imply that the HTTP server response
should be fully consumed and properly closed by the time the `exchange`
method returns. In other words, this HTTP client does not support
streaming the HTTP response.
This commit allows the `ResourceHttpMessageConverter` to be configured
to disable read streaming when used in `RestTemplate`.
Issue: SPR-14882
Prior to this commit, the `ResourceRegionHttpMessageConverter` would
rely on the default implementation of `getDefaultContentType` to guess
the default Content-Type of the resource region to be written to the
HTTP response. That implementation fetches the first media type
provided in the HTTP request "Accept" header.
This behavior is not correct when converting resources and this commits
aligns this converter with the `ResourceHttpMessageConverter` which uses
JAF to guess the correct Content-Type of the given resource, or just
returns "application/octet-stream" as a default value.
Issue: SPR-15041
The most common use case is specifying JSON views.
ServerResponse.BodyBuilder#hint(String, Object) allows to
specify response body serialization hints.
ServerRequest#body(BodyExtractor, Map) allows to specify
request body extraction hints.
Issue: SPR-15030
An update on the last commit switching from:
List<Locale> getAcceptLanguageAsLocales() to
Locale getAcceptLanguageAsLocale()
This best supports the scenario for the most preferred Locale.
If there is a need to look at the prioritized list of languages it's
best to use Locale.filter with the LocaleRange's.
This is explained in the Javadoc for getAcceptLanguage().
Issue: SPR-15024
The use of Locale.LanguageRange for the Accept-Language header makes
sense as it gives the most flexibility for a client to set a weighted
list and for a server to do filtering via Locale#filter.
This commit adds an additional convenience method that turns
the LangugeRange list to a list of Locale's also filtering out a
wildcard (i.e. "*"). A List<Locale> is the most basic way to access
prefered languages and needed when filtering is not required.
Issue: SPR-15024
