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
