Prior to this commit, flush calls on the output stream returned by
`ServletServerHttpResponse#getBody` would be delegated to the Servlet
response output stream.
This can cause performance issues when `HttpMessageConverter` and other
web components write and flush multiple times to the response body.
Here, the Servlet container is in a better position to flush to the
network at the optimal time and buffer the response body until then.
This is particularly true for `HttpMessageConverters` when they flush
many times the output stream, sometimes due to the underlying codec
library. Instead of revisiting the entire message converter contract, we
are here ignoring flush calls to that output stream.
This change does not affect the client side, nor the
`ServletServerHttpResponse#flush` calls.
This commit also introduces a new Spring property
`"spring.http.response.flush.enabled"` that reverts this behavior change
if necessary.
Closes gh-36385
The `AbstractMessageConverterMethodProcessor` is in charge of handling
controller method return values and to write those as HTTP response
messages. The content negotiation process is an important part.
The `MimeTypeUtils#sortBySpecificity` is in charge of sorting inbound
"Accept" media types by their specificity and reject them if the list
is too large, in order to protect the application from ddos attacks.
Prior to this commit, the content negotiation process would first get
the sorted "Accept" media types, the producible media types as
advertized by message converters - and collect the intersection of both
in a new list (also sorted by specificity). If the "Accept" list is
large enough (but under the limit), the list of compatible media types
could exceed that limit because duplicates could be introduced in that
list: several converters can produce the same content type.
This commit ensures that compatible media types are collected in a set
to avoid duplicates. Without that, exceeding the limit at this point
will throw an `InvalidMimeTypeException` that's not handled by the
processor and result in a server error.
Fixes gh-36300
Prior to this commit, the `HttpEntityMethodProcessor` would create a new
`ServletServerHttpRequest` input message to parse the native Servlet
request, but would not reuse it for reading the request body using the
message converters.
In gh-32471, we applied a change that updates HTTP headers accordingly
when request parameters are read. But not reusing the input message
means that we are losing this update when instantiating the resulting
`HttpEntity`.
This commit ensures that `HttpEntityMethodProcessor` uses the input
message it just created when decoding the request body.
Fixes gh-36298
This commit introduces ContextClassRequestBodyAdvice which adds a
"contextClass" hint allowing to resolve generics for Optional,
HttpEntity or ServerSentEvent container types.
Closes gh-36111
While an API version may be important for mapping in an ERROR dispatch,
it is more important to allow the original exception to be handled.
Closes gh-36058
Among HandlerMapping's some may not expect an API version. This is why
those that do must be careful not to raise API validation errors if
they don't match the request.
Closes gh-36059
This includes MethodParameter resolving getParameterName() by default now.
initParameterNameDiscovery(null) can be used to suppress such resolution.
Closes gh-36024
Return the requested resource as ErrorResponse.getDetailMessageArguments,
making it usable with message customization and i18n.
See gh-35758
Signed-off-by: Samuel Gulliksson <samuel.gulliksson@gmail.com>
Prior to this commit, Spring Framework's JSP form tags supported the
response encoding in most places; however, <form:select> and
<form:options> still did not support the response character encoding.
To address that, this commit updates SelectTag, OptionsTag, and
OptionWriter to provide support for response character encoding in the
`select` and `options` JSP form tags.
See gh-33023
Closes gh-35783
This commit updates Kotlin serialization converters to perform
an additional check invoking
KotlinDetector#hasSerializableAnnotation to decide if the
related type should be processed or not.
The goal is to prevent in the default arrangement conflicts
between general purpose converters like Jackson and
Kotlin serialization when both are used.
New constructors allowing to specify a custom predicate
are also introduced.
See gh-35761
Prior to this commit, the `HttpMessageConverters` builder API had
methods like "jsonMessageConverter" for configuring a specific converter
for JSON support. This converter would be always configured at a given
position, even if default converters registration is not requested.
On the other hand, `customMessageConverter` would add any converter
ahead of the list, in all cases. This difference was not conveyed as it
should by the API.
This commit makes the following changes:
* builder methods are renamed to `withJsonConverter` and variants, to
better convey the fact that those are replacing the default converter
for a given format.
* `customMessageConverter` is renamed to `addCustomConverter` to better
reflect the additive aspect.
* the JavaDoc has been updated accordingly
* `withJsonConverter` and others are now only effective if the default
registration of auto-detected converters is requested. This better
aligns with the behavior in the reactive codecs configuration
Closes gh-35704
Previous commit 81ea35c726 in main for 7.0
should have been applied in 6.2.x first for 6.2.1.
This commit applies the changes in 6.2.x as intended,
effective as of 6.2.13.
Closes gh-33974
Sam Brannen
조형준
Brian Clozel
rstoyanchev
Juergen Hoeller
Łukasz Jernaś
Sébastien Deleuze
木葉 Scarlet
Samuel Gulliksson
Vincent Potucek