Prior to this commit, Spring's MimeType checked for equality between
two MIME types based on the equality of their properties maps; however,
the properties maps contain string representations of the "charset"
values. Thus, "UTF-8" is never equal to "utf-8" which breaks the
contract for character set names which must be compared in a
case-insensitive manner.
This commit addresses this issue by ensuring that "charset" properties
in MimeType instances are compared as Java Charset instances, thereby
ignoring case when checking for equality between charset names.
Issue: SPR-13157
This commit adds canWrite() and write() methods to the
GenericHttpMessageConverter interface. These are type aware variants
of the methods available in HttpMessageConverter, in order to keep
parametrized type information when serializing objects.
AbstractMessageConverterMethodProcessor now calls those type aware
methods when the message converter implements GenericHttpMessageConverter.
AbstractJackson2HttpMessageConverter and GsonHttpMessageConverter uses
these new methods to make @ResponseBody method return type available
for type resolution instead of just letting the JSON serializer trying
to guess the type to use from the object to serialize.
Issue: SPR-12811
- Simplified "check" algorithms in CorsConfiguration
- Improved robustness of setter methods in CorsConfiguration in order to
avoid attempts to modify immutable lists
- Improved CORS documentation and fixed typo
- Introduced constants in CorsConfiguration
- Removed auto-boxing in CorsRegistration
Before this change HandlerMethodReturnValueHandler's were invoked in a
specific order (type-based, annotation-based, custom). However handlers
that deal with asynchronous return value handling need to always be
considered first. This affects custom handlers in particular since they
are normally ordered last.
This change introduces an AsyncHandlerMethodReturnValueHandler
sub-interface with a single method to determine if the return value is
asynchronous and if it is to look for a matching handler only among
those that are of type AsyncHandlerMethodReturnValueHandler.
Issue: SPR-13083
Before this change a missing path variable value resulted in a 400
error where in fact the error is due to a mismatch between the
declared @PathVariable and the URI template, i.e. a 500 error.
This change introduced a MissingPathVariableException as a sub-class
of ServletRequestBindingException (the exception previously thrown)
and results in a response status code of 500 by default.
Issue: SPR-13121
Prior to this change, the `"Last-Modified"` and "`Etag`" support had
been improved with SPR-11324: HTTP response headers are now
automatically added for conditional requests and more.
This commit fixes the format of the "`Last-Modified`" and "`ETag`"
values, which were using an epoch timestamp rather than an HTTP-date
format defined in RFC 7231 section 7.1.1.1.
Also, Conditional responses are only applied when the given response
applies, i.e. when it has an compatible HTTP status (2xx).
Issue: SPR-13090
This commit introduces support for RFC 7239: Forwarded HTTP Extension in
the UriComponentsBuilder. Unfortunately, RFC 7239 is not a complete
replacement for the X-Forwarded-* headers: specifically, there is not
direct replacement for X-Forwarded-Port. The JIRA contains more
information.
Issue: SPR-11856
This commit introduces first-class support for aliases for annotation
attributes. Specifically, this commit introduces a new @AliasFor
annotation that can be used to declare a pair of aliased attributes
within a single annotation or an alias from an attribute in a custom
composed annotation to an attribute in a meta-annotation.
To support @AliasFor within annotation instances, AnnotationUtils has
been overhauled to "synthesize" any annotations returned by "get" and
"find" searches. A SynthesizedAnnotation is an annotation that is
wrapped in a JDK dynamic proxy which provides run-time support for
@AliasFor semantics. SynthesizedAnnotationInvocationHandler is the
actual handler behind the proxy.
In addition, the contract for @AliasFor is fully validated, and an
AnnotationConfigurationException is thrown in case invalid
configuration is detected.
For example, @ContextConfiguration from the spring-test module is now
declared as follows:
public @interface ContextConfiguration {
@AliasFor(attribute = "locations")
String[] value() default {};
@AliasFor(attribute = "value")
String[] locations() default {};
// ...
}
The following annotations and their related support classes have been
modified to use @AliasFor.
- @ManagedResource
- @ContextConfiguration
- @ActiveProfiles
- @TestExecutionListeners
- @TestPropertySource
- @Sql
- @ControllerAdvice
- @RequestMapping
Similarly, support for AnnotationAttributes has been reworked to
support @AliasFor as well. This allows for fine-grained control over
exactly which attributes are overridden within an annotation hierarchy.
In fact, it is now possible to declare an alias for the 'value'
attribute of a meta-annotation.
For example, given the revised declaration of @ContextConfiguration
above, one can now develop a composed annotation with a custom
attribute override as follows.
@ContextConfiguration
public @interface MyTestConfig {
@AliasFor(
annotation = ContextConfiguration.class,
attribute = "locations"
)
String[] xmlFiles();
// ...
}
Consequently, the following are functionally equivalent.
- @MyTestConfig(xmlFiles = "test.xml")
- @ContextConfiguration("test.xml")
- @ContextConfiguration(locations = "test.xml").
Issue: SPR-11512, SPR-11513
`BeanWrapperImpl` and `DirectFieldAccessor` are two
`ConfigurablePropertyAccessor` implementations with different features
set.
This commit harmonizes the two implementations to use a common base class
that delegates the actual property handling to the sub-classes:
* `BeanWrapperImpl`: `PropertyDescriptor` and introspection utilities
* `DirectFieldAccessor`: reflection on `java.lang.Field`
Issues: SPR-12206 - SPR-12805
This commit introduces support for OkHttp
(http://square.github.io/okhttp/) as a backing implementation for
ClientHttpRequestFactory and AsyncClientHttpRequestFactory.
Issue: SPR-12893
After this change CorsProcessor has a single processRequest method and
it also explicitly deals with a null CorsConfiguration, which for
pre-flight requests results in a rejection while for simple requests
results in no CORS headers added.
The AbstractHandlerMapping now uses a LinkedHashMap to preserve the
order in which global patterns are provided.
This commit adds JavaConfig based global CORS configuration
capabilities to Spring MVC. It is now possible to specify
multiple CORS configurations, each mapped on a path pattern,
by overriding
WebMvcConfigurerAdapter#configureCrossOrigin(CrossOriginConfigurer).
It is also possible to combine global and @CrossOrigin based
CORS configuration.
Issue: SPR-12933
This change introduces a strategy for expanding a URI template into a
URI and makes it a property of the RestTemplate and AsyncRestTemplate
so that they can be pre-configured with such a strategy.
The DefaultUriTemplateHandler relies on UriComponentsBuilder internally
and provides functionality equivalent to using the UriTemplate.
A DefaultUriTemplateHandler can also be configured to parse the path
of a URI template into path segments in order to allow expanding URI
variables according to path segment encoding rules.
Issue: SPR-12750
Before this change AbstractHandlerMethodMapping used a map from Method
to CorsConfiguration. That works for regular @RequestMapping methods.
However frameworks like Spring Boot and Spring Integration may
programmatically register the same Method under multiple mappings,
i.e. adapter/gateway type classes.
This change ensures that CorsConfiguraiton is indexed by HandlerMethod
so that we can store CorsConfiguration for different handler instances
even when the method is the same.
In order for to make this work, HandlerMethod now provides an
additional field called resolvedFromHandlerMethod that returns the
original HandlerMethod (with the String bean name). This makes it
possible to perform reliable lookups.
Issue: SPR-11541
CorsConfiguration now provides methods to check and determine the
allowed origin, method, and headers according to its own configuration.
This simplifies significantly the work that needs to be done from
DefaultCorsProcessor. However an alternative CorsProcessor can still
access the raw CorsConfiguration and perform its own checks.
Issue: SPR-12885
This commit adds CORS related headers to HttpHeaders
and update DefaultCorsProcessor implementation to
use ServerHttpRequest and ServerHttpResponse instead
of HttpServletRequest and HttpServletResponse. Usage
of ServerHttpResponse allows to avoid using Servlet 3.0
specific methods in order keep CORS support Servlet 2.5
compliant.
Issue: SPR-12885
The onFailure callback and future.get() occur in different threads so
this change adds a latch to ensure we have both before asserting.
Issue: SPR-12887
AbstractHttpMessageConverter now tries to call getDefaultContentType
with the actual value to be converted to see if that will result in
a more concrete mediat type than application/octet-stream.
Issue: SPR-12894
This commit introduces support for CORS in Spring Framework.
Cross-origin resource sharing (CORS) is a mechanism that allows
many resources (e.g. fonts, JavaScript, etc.) on a web page to
be requested from another domain outside the domain from which
the resource originated. It is defined by the CORS W3C
recommandation (http://www.w3.org/TR/cors/).
A new annotation @CrossOrigin allows to enable CORS support
on Controller type or method level. By default all origins
("*") are allowed.
@RestController
public class SampleController {
@CrossOrigin
@RequestMapping("/foo")
public String foo() {
// ...
}
}
Various @CrossOrigin attributes allow to customize the CORS configuration.
@RestController
public class SampleController {
@CrossOrigin(origin = { "http://site1.com", "http://site2.com" },
allowedHeaders = { "header1", "header2" },
exposedHeaders = { "header1", "header2" },
method = RequestMethod.DELETE,
maxAge = 123, allowCredentials = "true")
@RequestMapping(value = "/foo", method = { RequestMethod.GET, RequestMethod.POST} )
public String foo() {
// ...
}
}
A CorsConfigurationSource interface can be implemented by HTTP request
handlers that want to support CORS by providing a CorsConfiguration
that will be detected at AbstractHandlerMapping level. See for
example ResourceHttpRequestHandler that implements this interface.
Global CORS configuration should be supported through ControllerAdvice
(with type level @CrossOrigin annotated class or class implementing
CorsConfigurationSource), or with XML namespace and JavaConfig
configuration, but this is not implemented yet.
Issue: SPR-9278
This commit adds a filters property to MappingJacksonValue
and also manages a special FilterProvider class name model key in
order to be able to specify a customized FilterProvider for each
handler method execution, and thus provides a more dynamic
alternative to our existing JsonView support.
A filters property is also now available in Jackson2ObjectMapperBuilder
and Jackson2ObjectMapperFactoryBean in order to set easily a
global FilterProvider.
More details about @JsonFilter at
http://wiki.fasterxml.com/JacksonFeatureJsonFilter.
Issue: SPR-12586
This commit introduces support for "Path Segment URI Variable
expansion", see https://tools.ietf.org/html/rfc6570#section-3.2.6.
In practice, this means that URI template variables prefixed with a '/'
are treated like path segments and - as such - will encode any '/'
found. For example: {/foo} expanded with "bar/baz" with result in
"bar%2F".
Issue: SPR-12750
This reverts commit a57d42829c after the
realization of a weaknesses with the proposed approach.
For example if a path segment contains both a /-prefixed and a regular
URI variable, there is no way to split that into a sequence of path
and path segments. The solution will have to be on the side of
UriComponents at the time of encoding.
Prior to this commit, Cache-Control HTTP headers could be set using
a WebContentInterceptor and configured cache mappings.
This commit adds support for cache-related HTTP headers at the controller
method level, by returning a ResponseEntity instance:
ResponseEntity.status(HttpStatus.OK)
.cacheControl(CacheControl.maxAge(1, TimeUnit.HOURS).cachePublic())
.eTag("deadb33f8badf00d")
.body(entity);
Also, this change now automatically checks the "ETag" and
"Last-Modified" headers in ResponseEntity, in order to respond HTTP
"304 - Not Modified" if necessary.
Issue: SPR-8550
This commit improves HTTP caching defaults and flexibility in
Spring MVC.
1) Better default caching headers
The `WebContentGenerator` abstract class has been updated with
better HTTP defaults for HTTP caching, in line with current
browsers and proxies implementation (wide support of HTTP1.1, etc);
depending on the `setCacheSeconds` value:
* sends "Cache-Control: max-age=xxx" for caching responses and
do not send a "must-revalidate" value by default.
* sends "Cache-Control: no-store" or "Cache-Control: no-cache"
in order to prevent caching
Other methods used to set specific header such as
`setUseExpiresHeader` or `setAlwaysMustRevalidate` are now deprecated
in favor of `setCacheControl` for better flexibility.
Using one of the deprecated methods re-enables previous HTTP caching
behavior.
This change is applied in many Handlers, since
`WebContentGenerator` is extended by `AbstractController`,
`WebContentInterceptor`, `ResourceHttpRequestHandler` and others.
2) New CacheControl builder class
This new class brings more flexibility and allows developers
to set custom HTTP caching headers.
Several strategies are provided:
* `CacheControl.maxAge(int)` for caching responses with a
"Cache-Control: max-age=xxx" header
* `CacheControl.noStore()` prevents responses from being cached
with a "Cache-Control: no-store" header
* `CacheControl.noCache()` forces caches to revalidate the cached
response before reusing it, with a "Cache-Control: no-store" header.
From that point, it is possible to chain method calls to craft a
custom CacheControl instance:
```
CacheControl cc = CacheControl.maxAge(1, TimeUnit.HOURS)
.cachePublic().noTransform();
```
3) Configuring HTTP caching in Resource Handlers
On top of the existing ways of configuring caching mechanisms,
it is now possible to use a custom `CacheControl` to serve
resources:
```
@Configuration
public class MyWebConfig extends WebMvcConfigurerAdapter {
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
CacheControl cc = CacheControl.maxAge(1, TimeUnit.HOURS);
registry.addResourceHandler("/resources/**)
.addResourceLocations("classpath:/resources/")
.setCacheControl(cc);
}
}
```
or
```
<mvc:resources mapping="/resources/**" location="classpath:/resources/">
<mvc:cachecontrol max-age="3600" cache-public="true"/>
</mvc:resources>
```
Issue: SPR-2779, SPR-6834, SPR-7129, SPR-9543, SPR-10464
This change improves the following use cases with
`WebRequest.checkNotModified(String etag)` and
`WebRequest.checkNotModified(long lastModifiedTimeStamp)`:
1) Allow weak comparisons for ETags
Per rfc7232 section-2.3, ETags can be strong or weak;
this change allows comparing weak forms `W/"etagvalue"` but does
not make a difference between strong and weak comparisons.
2) Allow multiple ETags in client requests
HTTP clients can send multiple ETags values in a single header such as:
`If-None-Match: "firstvalue", "secondvalue"`
This change makes sure each value is compared to the one provided by
the application side.
3) Extended support for ETag values
This change adds padding `"` to the ETag value provided by
the application, if not already done:
`etagvalue` => `"etagvalue"`
It also supports wildcard values `*` that can be sent by HTTP clients.
4) Sending validation headers for 304 responses
As defined in https://tools.ietf.org/html/rfc7232#section-4.1
`304 Not Modified` reponses must generate `Etag` and `Last-Modified`
HTTP headers, as they would have for a `200 OK` response.
5) Providing a new method to validate both Etag & Last-Modified
Also, this change adds a new method
`WebRequest.checkNotModified(String etag, long lastModifiedTimeStamp)`
in order to support validation of both `If-None-Match` and
`Last-Modified` headers sent by HTTP clients, if both values are
supported by the application code.
Even though this approach is recommended by the HTTP rfc (setting both
Etag and Last-Modified headers in the response), this requires more
application logic and may not apply to all resources produced by the
application.
Issue: SPR-11324
This commit introduces support for HTTP byte ranges in the
ResourceHttpRequestHandler. This support consists of a number of
changes:
- Parsing of HTTP Range headers in HttpHeaders, using a new HttpRange
class and inner ByteRange/SuffixByteRange subclasses.
- MIME boundary generation moved from FormHttpMessageConverter to
MimeTypeUtils.
- writePartialContent() method introduced in ResourceHttpRequestHandler,
handling the byte range logic
- Additional partial content tests added to
ResourceHttpRequestHandlerTests.
Issue: SPR-10805
After this change UriComponentsBuilder#uriComponents method no longer
no longer copies from the given UriComponents but rather lets the
UriComponents instance copy itself to the UriComponentsBuilder.
This avoids the need for instanceof checks and also makes it possible
to distinguish between path and path segments, which otherwise is
internal knowledge of UriComponentsBuilder.
Issue: SPR-12742
Revised HandlerMethod.getBeanType() impl for both web and messaging.
In addition, HandlerMethods get created with the internal BeanFactory now.
Issue: SPR-12832
Prior to this commit, the ContentCachingRequestWrapper would immediately
consume the wrapped request's InputStream when asked for the cached
content; that caused several issues:
* the request body was read in memory even if it wasn't yet consumed by
the application, leading to inefficiencies.
* when requesting the InputStream, an empty InputStream was returned
since the original was already read.
This case only happened for form POSTs requests.
This commit makes sure that the wrapper does not alter the request
expected behavior:
* when getting the inputstream, it is wrapped in order to cache its
content
* when getting request parameters, the request body is cached and its
inputstream is consumed, as expected
Issue: SPR-12810
All HttpMessageConverters should support StreamingHttpOutputMessage.
Specifically, the BufferedImageHttpMessageConverter and
FormHttpMessageConverter should do so.
Issue: SPR-12715
With this commit, WebUtils.isValidOrigin() logs an error message instead
of throwing an IllegalArgumentException when Origin header value is
invalid (for example when it does not contain the scheme).
Issue: SPR-12697
This commit adds support for a same origin check that compares
Origin header to Host header. It also changes the default setting
from all origins allowed to only same origin allowed.
Issues: SPR-12697, SPR-12685
Before this change, detection of X-Forwarded-* headers was only built
into ServletUriComponentsBuilder.
This change adds a new method for creating a UriComponentsBuilder from
an existing HttpRequest. This is equivalent to the fromUri method +
X-Forwarded-* header values.
This commit also adds a modules(Module...) method in addition to
modules(List<Module> modules) in order to be consistent with other
parts of the API.
Issue: SPR-12634
Before this change, the maxRequestSize property was used (incorrectly)
to limit both the size of the request and response. The change:
- removes maxRequestSize and therefore no longer places limits on the
size of the request thus matching to AbstractBufferingClientHttpRequest
which is the base class for other buffering client implementations.
- adds maxResponseSize property required to create Netty's
HttpObjectAggregator for aggregating responses.
Issue: SPR-12623
This commit adds ResponseBodyEmitter and SseEmitter (and also
ResponseEntity<ResponseBodyEmitter> and ResponseEntity<SseEmitter>) as
new return value types supported on @RequestMapping controller methods.
See Javadoc on respective types for more details.
Issue: SPR-12212
Prior to this commit, the `ContentCachingRequestWrapper` class would
cache the response content only if the reponse would be consumed using
its InputStream. In case of a Form request, Spring MVC consumes the
response using the `getParameter*` Servlet API methods. This causes the
cached content to never be written.
This commit makes the `ContentCachingResponseWrapper` write the request
body to the cache buffer by using the `getParameter*` API, thus avoiding
those issues.
Issue: SPR-7913
Modules (well-known or user provided) registration is now performed
first in order to allow their configuration to be customized by more
specific ones like custom serializers or deserializers.
Issue: SPR-12634
Prior to this commit, HTTP responses without body (response status 204
or 304, Content-Length: 0) were handled properly by RestTemplates. But
some other cases were not properly managed, throwing exceptions for
valid HTTP responses.
This commit better handles HTTP responses, using a response wrapper that
can tell if a response:
* has no message body (HTTP status 1XX, 204, 304 or Content-Length:0)
* has an empty message body
This covers rfc7230 Section 3.3.3.
Issue: SPR-8016
Prior to this change, the ShallowEtagHeaderFilter would use a
ResizableByteArrayOutputStream to internally write data and calculate
the ETag. While that implementation is faster than the regular
ByteArrayOutputStream (since it has a better strategy for growing the
internal buffer), a lot of buffer copying/writing still happens.
This change adds a new FastByteArrayOutputStream implementation that
internally uses a LinkedList<Byte[]> to store the content. So when
writing bytes to that OutputStream implementation, new byte[] are
added to the list when the previous ones are full. This saves most
of the instantiating/copying operations.
Note that new methods were added in DigestUtils to allow usage of
Streams instead of byte[], which is more efficient in our case.
Fixes#653
Issue: SPR-12081
Update HttpComponents wrapper to merge local customizations with the
default of the current HttpClient instead of overriding everything.
This is available as from HttpComponents 4.4. that exposes the default
request config from the client via the Configurable interface. If the
client does not implement such interface, the previous behaviour is
applied
Issue: SPR-12583
Prior to this commit, some requests would be wrongly mapped to "/" when:
* requests ends with "//" such as "/foo/bar//"
* the DispatcherServlet is mapped as the default ("/")
* the app container sanitizes the servletPath
In those cases, the path extraction algorithm was wrongly guessing the
path of the current request.
This commit detects if the app container sanitized the servletPath for
the current request. If so, it uses a sanitized version of the
requestUri to extract the path information.
Issue: SPR-12372
Previously the default settings of a custom HttpClient were always
ignored since a RequestConfig instance was always set no matter if
some customizations were applied or not.
This commit keeps an internal RequestConfig object instance that is
only initialized if the user applies a customization. If he does not, the
default settings of the HttpClient are used as it should.
Note that if the HttpComponents API exposed the default RequestConfig
of a given HttpClient, we would be able to merge our customizations with
the one specified by the client. Unfortunately, such API does not exist
and the "defaultSettingsOfHttpClientLostOnExecutorCustomization" test
illustrates that limitation.
Issue: SPR-12540
Before this change attributes listed with @SessionAttributes would not
be saved in the session when there was a redirect and the controller
method declared a parameter of type RedirectAttributes.
This change ensures it's the "default" model that is always the one
checked for @SessionAttributes under all circumstances since
RedirectAttributes is really only meant to provide String values to
insert into or append to the the redirect URL.
Issue: SPR-12542
Prior to this commit it was not possible to easily customize the
connection request timeout used by the HttpClient. Both
`HttpComponentsClientHttpRequestFactory` and
`HttpComponentsClientHttpRequestFactoryTests` have been updated to
support a `connectionRequestTimeout` property.
Issue: SPR-12166
Previously, HttpComponentsHttpInvokerRequestExecutor was not compatible
with the new API of HttpComponents 4.3. Specifically, it is not possible
to update the socket and read timeouts on the HttpClient itself anymore.
We actually already updated HttpComponentsClientHttpRequestFactory for a
similar problem in SPR-11442: if we detect an older HttpClient
implementation, we update the timeout directly on the client. If that's
not the case, we keep the value in the factory itself and use it when a
new HttpRequest needs to be created.
This commit also uses the new API to create a default HttpClient and
therefore requires HttpComponents 4.3. As mentioned above, it is still
possible to use deprecated HttpClient instances against this executor.
Issue: SPR-11113
This commit introduces the SpringHandlerInstantiator
class, a Jackson HandlerInstantiator that allows to autowire
Jackson handlers (JsonSerializer, JsonDeserializer, KeyDeserializer,
TypeResolverBuilder and TypeIdResolver) if needed.
SpringHandlerInstantiator is automatically used with
@EnableWebMvc and <mvc:annotation-driven />.
Issue: SPR-10768
Prior to this change, RestTemplate returned an empty response body if:
* HTTP return status 204 or 304
* Content-length header equals 0
This change adds a new condition for this, better supporting RFC7230
section 3.4, for connections that are closed without response body:
* No Content-length header
* No Transfer-encoding: chunked header value
* a Connection: close header value
See SPR-7911 for previous efforts in that space.
Issue: SPR-8016
With this commit, Jackson builder is now used in spring-websocket
to create the ObjectMapper instance.
It is not possible to use the builder for spring-messaging
and spring-jms since these modules don't have a dependency on
spring-web, thus they now just customize the same features:
- MapperFeature#DEFAULT_VIEW_INCLUSION is disabled
- DeserializationFeature#FAIL_ON_UNKNOWN_PROPERTIES is disabled
Issue: SPR-12293
FormHttpMessageConverter incorrectly determines that the media type
"multipart/form-data; charset=utf-8" is not multipart. This commit
allows the media type to contain a charset parameter.
The following commit allowed HTTP DELETE with body:
584b831bb9
However it broke buffered requests even without a body since JDK 1.6
and 1.7 do not support calls to getOutputStream with HTTP DELETE.
This commit set the doOutput flag back to false if the actual buffered
body is 0 length.
Issue: SPR-12361
With SPR-9293, it is now possible to HTML escape text while taking into
account the current response encoding. When using UTF-* encodings, only
XML markup significant characters are escaped, since UTF-* natively
support those characters.
This commit adds a new servlet context parameter to enable this fix by
default in a Spring MVC application:
<context-param>
<param-name>responseEncodedHtmlEscape</param-name>
<param-value>true</param-value>
</context-param>
Issue: SPR-12350, SPR-12132
During the HTTP Content Negotiation phase, the ContentNegotiationManager
uses configured ContentNegotiationStrategy(ies) to define the list of
content types accepted by the client.
When HTTP clients don't send Accept headers, nor use a configured
file extension in the request, nor a request param, developers can
define a default content type using the
ContentNegotiationConfigurer.defaultContentType() method.
This change adds a new overloaded defaultContentType method that takes a
ContentNegotiationStrategy as an argument. This strategy will take the
current request as an argument and return a default content type.
Issue: SPR-12286
This commit adds new htmlEscape methods that take the character encoding
as a parameter. According to specs and recommendations, the list of
chars to be html escaped depends on the encoding used in the response.
If the current char encoding supports chars natively, we shouldn't
escape those; of course, reserved chars (<,>,',",&) should always be
escaped.
See: http://www.w3.org/TR/html4/sgml/entities.html#h-24.3
See: spring-projects/spring-framework#385 by @candrews
Issue: SPR-9293
Before this change, the type of asynchronously produced return values
(e.g. Callable, DeferredResult, ListenableFuture) could not be
properly determined with an actual resulting value of null. Or even
with an actual value returned, the generic type could not be properly
determined. This change fixes both of those issues.
Issue: SPR-12287
This commit adds support for direct Jackson mix-in annotations registration in
Jackson2ObjectMapperFactoryBean and Jackson2ObjectMapperBuilder.
Issue: SPR-12144
Jackson2ObjectMapperBuilder now allows to create ObjectMapper and XmlMapper
instances easily thanks to its fluent API.
This builder is used in Jackson message converters and views to instantiate default
ObjectMapper and XmlMapper.
This commit also add a createXmlMapper property to
Jackson2ObjectMapperFactoryBean in order to allow to create easily a XmlMapper
instance.
Issue: SPR-12243
Prior to this commit, the `ProtobufHttpMessageConverter` would call
`outputMessage.getBody()` at the beginning of the `writeInternal`
method, thus writing HTTP headers. Since this method is trying to write
"x-protobuf" headers after that, protobuf support wasn't working
properly for the default "x-protobuf" media type.
Thanks Toshiaki Maki for the repro project!
Also fixed:
* improve `MockHttpOutputMessage` behavior to reproduce the read-only
state of HTTP headers once they've been written.
Issue: SPR-12229
This commit makes it possible to specify port with an URI template variable.
For example :
RestTemplate restTemplate = new RestTemplate();
restTemplate.getForObject("http://localhost:{port}/resource", String.class, 8080);
Issue: SPR-12123
Sam Brannen
Sebastien Deleuze
Rossen Stoyanchev
Juergen Hoeller
izeye
Stephane Nicoll
Brian Clozel
Arjen Poutsma
Luciano Leggieri
Markus Malkusch
Radosław Józwik
Juergen Hoeller
Craig Andrews
Stephane Nicoll
Alex Antonov
Roy Clarkson
Tadaya Tsuyukubo
Phillip Webb