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
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
This commit removes duplicate slashes in the resolved lookup path when
calling `UrlPathHelper.getLookupPathForRequest`. This is especially
necessary when the path is cleaned from semicolon content and leaves
duplicate slashes in the request path.
Issue: SPR-13455
The inner MimeTypeResolver class is no longer necessary in the
MockServletContext since the Java Activation Framework (JAF) is a
standard part of Java SE since Java 6.
This commit adds support for origins with a trailing slash or a path,
in order to avoid printing a stacktrace in the logs when
WebUtils#isSameOrigin(HttpRequest) parses such invalid Origin header
value.
Issue: SPR-13478
This commit migrates all remaining tests from JUnit 3 to JUnit 4, with
the exception of Spring's legacy JUnit 3.8 based testing framework that
is still in use in the spring-orm module.
Issue: SPR-13514
Before this commit UriComponents was capable of expanding URI vars that
may have contained a regular expressions (as supported with
@RequestMapping for example). However if the regular expressions
contained any nested "{}" the expand did not work correctly.
This commit sanitizes a URI template source removing any content
between nested "{}" prior to expanding. This works since we only care
about the URI variable name.
Issue: SPR-13311
Prior to this change, trying to set an unquoted ETag with
`ResponseEntity`'s API would throw an `IllegalArgumentException`.
This commit automatically quotes ETag values set using ResponseEntity.
Issue: SPR-13378
In an attempt to make our Jetty-based integration tests more robust,
this commit discontinues use of SocketUtils for picking a random,
available port and instead lets the Jetty Server pick its own port.
Before this commit RequestPartServletServerHttpRequest simply did an
instanceof check for MultipartHttpServletRequest. That hasn't failed
because request wrapping typically happens in filters before the
DispatcherServlet calls the MultipartResolver.
With Spring MVC Test and the Spring Security integraiton however,
this order is reversed since there we prepare the multipart request
upfront, i.e. there is no actual parsing.
The commit unwraps the request if necessary.
Issue: SPR-13317
This change ensures that an onError outcome from an async request is
also routed to onCompletion handlers registered with
StandardServletAsyncWebRequest.
Issue: SPR-13292
Prior to this change, calling the `setDateHeader` method on a
Spring Test MockHttpServletResponse instance would just store the given
long value in a Map, not writing it as a formatted date String.
Also, calling `getDateHeader` on a MockHttpServletRequest would not
support date strings and could not parse those values.
This can be problematic when testing features related to date headers
such as "Expires", "If-Modified-Since", "Last-Modified", etc.
This commit adds formatting and parsing capabilities to Servlet Mocks
for date strings in HTTP headers.
When formatting dates to Strings, the date format used is the one
preferred by the HTTP RFC. When parsing date Strings, multiple date
formats are supported for better compatibility.
Issue: SPR-11912
Prior to this change, calling the `setDateHeader` method on a
MockHttpServletResponse instance (internal implementation for testing
the spring-web module) would just store the given long value in a Map,
not writing it as a formatted date String.
This can be problematic when testing features related to date headers
such as "Expires", "If-Modified-Since", "Last-Modified", etc.
This commit formats long dates into date Strings using the date format
recommended by the RFC and the GMT time zone.
