Prior to this commit, the WebFlux server support would try reading
form-data from the request by:
* first, checking that request content-type is compatible with a
form-data content-type
* then by selecting a message reader that is compatible with the given
request content-type
This approach is flawed because if the content-type provided by the
request is too broad, another message reader could be selected that's
not meant to be used for reading form-data. Typically, a JSON message
reader could be selected and would fail when reading the request.
This problem was previously hidden because message readers would not
support `MultiValueMap` as a target type. Now that some readers support
this type, this can lead to deserialization errors.
This commit now ensures that in all cases, we attempt to read form-data
with a message reader that supports the
"application/x-www-form-urlencoded" media type.
Fixes gh-34660
While we choose our GitHub action to use Bellsoft Liberica, we should
relax that vendor requirement and ensure that contributors can build the
project with any Java 24 distribution.
Closes gh-35043
Use String.replace instead of replaceAll in MetadataEncoder; since Java 9, String.replace
no longer uses a regex, while replaceAll does. The use case here of replacing a single
character does not require a regex.
Closes gh-35025
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
Prior to this commit, the "filename" parameter value for the
"Content-Disposition" header would contain non-printable characters,
causing parsing issues for HTTP clients.
This commit ensures that all non-printable characters are encoded.
Fixes gh-35034
Due to lacking support in NullAway for the current arrangement, we are
(perhaps temporarily) changing the signature of the execute() method in
RetryOperations (and thus also in RetryTemplate)...
from: <R extends @Nullable Object> R execute(Retryable<R> retryable);
to: <R> @Nullable R execute(Retryable<? extends @Nullable R> retryable);
Once https://github.com/uber/NullAway/issues/1075 has been resolved, we
will consider switching back to the original signature.
See gh-34716
