This commit adds support for the "SameSite" attribute in response
cookies. As explained in rfc6265bis, this attribute can be used to limit
the scope of a cookie so that it can't be attached to a request unless
it is sent from the "same-site".
This feature is currently supported by Google Chrome and Firefox, other
browsers will ignore this attribute.
This feature can help prevent CSRF attacks; this is why this commit adds
this attribute by default for SESSION Cookies in WebFlux.
See: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis
Issue: SPR-16418
Also, ZeroCopyHttpOutputMessage provides writeWith(Path, int, int), enforcing that variant as the implementation target in 5.1 (analogous to FilePart).
Issue: SPR-16925
@PathVariable's javadoc states that it supports MultiValueMap
parameters (introduced by commit df0902), but by reading through the
code, that does not seem to be the case (compare, e.g.,
PathVariableMapMethodArgumentResolver to
RequestParamMapMethodArgumentResolver).
Moreover, parsing MultipleValueMap is done according to the ";"
character, and placing such a character in a path (e.g., consider
something like "/app/{param}/show" would just break the path.
This patch fixes PathVariable's javadoc by removing the mention of
MultiValueMap.
This commit fixes the write checks for
`ResourceRegionHttpMessageConverter`, which was previously not checking
properly the parameterized type (e.g. in case of a `List<Something>`).
Issue: SPR-16932
This commit restricts the allowed HTTP methods on HiddenHttpMethodFilter
(Reactive variant) to the following: PUT, DELETE, PATCH.
This filter is meant to be used to simulate those methods from HTML
forms sent by browsers, so no other methods are allowed.
Issue: SPR-16836
This commit restricts the allowed HTTP methods on HiddenHttpMethodFilter
(Servlet variant) to the following: PUT, DELETE, PATCH.
This filter is meant to be used to simulate those methods from HTML
forms sent by browsers, so no other methods are allowed.
Issue: SPR-16836
Prior to this commit, the generated POMs for Spring Framework modules
would contain unneeded/harmful information from the Spring Framework
build:
1. The BOM imports applied to each module by the dependency
management plugin, for example for Netty or Reactor Netty.
Spring should not export that opinion to its POMs.
2. The exclusion of "org.slf4:jcl-over-slf4j" from *all* dependencies,
which made the POMs much larger than necessary and suggested to
developers that they should exclude it as well when using all those
listed dependencies. In fact, only Apache Tiles currently brings that
transitively.
This commit removes that information from the POMs.
The dependencyManagement Gradle plugin is disabled for POM generation
and we manually resolve the dependency versions during the generation
phase.
The Gradle build is streamlined to exclude "org.slf4:jcl-over-slf4j"
only when necessary.
Issue: SPR-16893
After the Groovy 2.5 upgrade, the Spring Framework build on JDK9 hit
GROOVY-8631. Adding the relevant `jax-api` dependency to the module
didn't fix this issue. The Groovy release notes mention the use of the
`--add-modules` JVM flag, but this is not an option for this build which
should run on JDK8 -> JDK11.
This commit changes the dependency from `groovy-all` to more focused
dependencies on Groovy in the `spring-beans` and `spring-context`
modules. This change seems to avoid the automatic loading of Groovy
enhancements to JAXB (shipped with `groovy-xml`).
See:
* http://groovy-lang.org/releasenotes/groovy-2.5.html#Groovy2.5releasenotes-Knownissues
* https://issues.apache.org/jira/browse/GROOVY-8631
Issue: SPR-15407
Sam Brannen
Rossen Stoyanchev
Brian Clozel
Juergen Hoeller
Dave Syer
Allon Mureinik
Stephane Nicoll
Yun
Sebastien Deleuze