Prior to this commit, setting the `forceEncoding` option would force
encoding on both requests and responses.
This commit adds two new setters and a new constructor to differentiate
both options: forcing the encoding on the request and/or on the
response.
You can now define this filter programmatically using those options or
update your servlet XML configuration like:
```
<filter>
<filter-name>characterEncodingFilter</filter-name>
<filter-class>o.sf.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceRequestEncoding</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>forceResponseEncoding</param-name>
<param-value>false</param-value>
</init-param>
</filter>
```
Issue: SPR-14240
Prior to this commit, the `ResourceHttpMessageConverter` would support
all HTTP Range requests and `MethodProcessors` would "wrap" controller
handler return values with a `HttpRangeResource` to support that use
case in Controllers.
This commit refactors that support in several ways:
* a new ResourceRegion class has been introduced
* a new, separate, ResourceRegionHttpMessageConverter handles the HTTP
range use cases when serving static resources with the
ResourceHttpRequestHandler
* the support of HTTP range requests on Controller handlers has been
removed until a better solution is found
Issue: SPR-14221, SPR-13834
This commit makes sure that HTTP request headers containing ETag values
are properly parsed and not simply tokenized using a "," separator.
Indeed, ETags can legally contain separator characters such as " " and
",".
Issue: SPR-14216
Prior to this change, getting header values with `HttpHeaders` when
headers are multi-valued would cause issues.
For example, for a given HTTP message with headers:
Cache-Control: public, s-maxage=50
Cache-Control: max-age=42
Getting a `List` of all values would return <"public", "s-maxage=50">
and getting the header value would return "public, s-maxage=50".
This commit takes now into account multi-valued HTTP headers and adds
new getters/setters for "If-Match" and "If-Unmodified-Since" headers.
Note that for ETag-related headers such as "If-Match" and
"If-None-Match", a special parser has been implemented since ETag values
can contain separator characters.
Issue: SPR-14223, SPR-14228
Prior to this change, setting both "If-None-Match" and
"If-Unmodified-Since" conditional request headers would check for both
conditions to be met.
This commit fixes this behavior to follow the RFC7232 Section 6:
> entity tags are presumed to be more accurate than date validators
So in case both conditions are present, the "If-None-Match" condition
takes precedence.
Issue: SPR-14224