Prior to this commit, @ModelAttribute(binding=false) was honored with
Spring Web MVC but not with WebFlux.
This commit adds support for disabling binding via @ModelAttribute with
WebFlux by adding a check to resolveArgument(...) in
ModelAttributeMethodArgumentResolver.
Closes gh-26856
Prior to this commit, evaluating validation hints for
@javax.validation.Valid caused exceptions being raised when getting the
value of this annotation, which does not exist. Bypassing
AnnotationUtils.getValue() in those cases can improve performance by
avoiding the cost incurred by raising exceptions.
See gh-26787
This commit introduces support in both servlet and webflux for the
"Accept-Patch" header, which is sent when the client sends unsupported
data in PATCH requests.
See section 2.2 of RFC 5789.
Closes gh-26759
This commit introduces support in both servlet and webflux for the
"Accept-Patch" header in OPTIONS requests, as defined in section 3.1 of
RFC 5789.
See gh-26759
Prior to this commit, a method-level @CrossOrigin maxAge value did not
override a class-level @CrossOrigin maxAge value. This contradicts the
Javadoc for @CrossOrgin which states the following.
For those attributes where only a single value can be accepted such
as allowCredentials and maxAge, the local overrides the global
value.
This commit ensures that a method-level @CrossOrigin maxAge value
overrides a class-level @CrossOrigin maxAge value.
Closes gh-26619
Prior to this commit, `ResourceUrlProvider` would listen and consider
all `ContextRefreshedEvent` and use the given context to detect
`SimpleUrlHandlerMapping`.
This could lead to situations where a `ResourceUrlProvider` uses another
application context than its own (in a parent/child context setup) and
detect the wrong set of handlers.
Because `ResourceUrlProvider` locks itself once the auto-detection is
done, we need to ensure that it considers only events sent by its
application context.
Fixes gh-26561
1. Update the HandlerMapping contract to state that CORS checks are expected
to be applied before returning a handler.
2. DispatcherHandler checks explicitly for pre-flight requests or CORS failed
requests and skips handling for both. Technically no change since
AbstractHandlerMapping already returns a NO_OP_HANDLER for those cases.
The purpose however is for the DispatcherHandler to also guarantee more
explicitly that no such handling can take place for such cases.
As one consequence, this makes it possible to invoke the DispatcherHandler from
anywhere in the WebFilter chain in order to "handle" a pre-flight request, and
then skip the rest of the WebFilter chain.
See gh-26257
Sébastien Deleuze
ShindongLee
Rossen Stoyanchev
Sam Brannen
Johnny Lim
Christoph Dreis
Stephane Nicoll
Mustafa Ulu
Juergen Hoeller
Arjen Poutsma
Valentin
sokomishalov
GungnirLaevatain
fengyuanwei
Brian Clozel
gaerfield
Mattison chao
mplain