AsyncRequestExecution now properly supports decoration of the
request (URI, HTTP method, and headers).
Removed a no-op IdentityListenableFutureAdapter.
Use Spring Framework coding style.
Issue: SPR-12538
Fixed a bug where the URL content negotiation "format" parameter values
were case sensitive and only lowercase values were accepted. For
example, URL query parameter format=json returned the appropriate JSON
response but format=JSON resulted in a
HttpMediaTypeNotAcceptableException and returned:
406 - The resource identified by this request is only capable of
generating responses with characteristics not acceptable according to
the request "accept" headers.
When the MappingMediaTypeFileExtensionResolver is constructed, it is
passed a map containing the media type key to MediaType mappings
defined in the ContentNegotiationConfigurer. In the constructor of
MappingMediaTypeFileExtensionResolver, the keys are converted to
lowercase and the mappings of keys to MediaTypes are added to the
ConcurrentMap<String, MediaType> mediaTypes using the lowercase
version of the keys. However, when retrieving the MediaType from a key
in the lookupMediaType method, no conversion to lowercase is performed
so any value for the URL "format" parameter other than the lowercase
version will not return the proper MediaType result.
On May 1st, 2014, a change was made to
ParameterContentNegotiationStrategy to handle cases where the content
negotiation format URL parameter does not result in a match for a
MediaType. If no match is found, a HttpMediaTypeNotAcceptableException
is thrown resulting in the 406 response above. Prior to this commit, a
null was returned instead of throwing an exception so this issue was
hidden and appeared to function correctly.
To make the media type lookup case insensitive, added a line to the
lookupMediaType method in MediaTypeFileExtensionResolver to first
convert the extension (media type key) to lowercase prior to attempting
to retrieve it from the mediaTypes map.
Issue: SPR-13747
The recent commit 971f04 replaced the use of a NAMES_PATTERN regex in
favor of direct parsing in order to deal with nested curly braces.
The change also incorrectly replicated this logic which removes a
trailing slash after Pattern quoting (and not before):
cca037a74d/spring-web/src/main/java/org/springframework/web/util/UriTemplate.java (L207-L210)
After some more investigation there doesn't appear to be any scenario
where the quoted pattern would end with a trailing slash. It should
always end with \E (end of quote) or a ")" (end of group). Nor are
there any failing tests so this commit removes the logic altogether.
Issue: SPR-13705
Prior to this commit, when adding a ShallowEtagHeaderFilter to an
application, the ServletResponse would be wrapped by a
ContentCachingResponseWrapper. When any part of the Spring
infrastructure calls `flushBuffer` on the wrapped response, the call is
delegated to the actual response, which is committed. It's not possible
to alter the response (headers, content) anymore - the ETag filter can't
act.
This change prevents the `flushBuffer` call to be delegated and only
commits the underlying response once the cached content is copied to the
actual response stream.
Issue: SPR-13717
This commit expands the range of whitelisted extensions by checking
if an extension can be resolved to image/*, audo/*, video/*, as well
as any content type that ends with +xml.
Issue: SPR-13643
The URI template is now manually parsed vs using a regex to extract
URI variable names and to create a pattern for matching to actual URLs.
This provides more control to deal with nested curly braces.
Issue: SPR-13627
Add new MediaType.APPLICATION_JSON_UTF8 and
MediaType.APPLICATION_JSON_UTF8_VALUE constants for
"application/json;charset=UTF-8" content type in order to make it
easier to override @RequestMapping "produces" attribute without
losing the default JSON charset (UTF-8).
Issue: SPR-13600
