The method was orginally added under SPR-14547 but the example in it
was probably intended for use with Content-Disposition server response
header (file download) and not for a Content-Disposition header
within the body of a multipart request.
In a Spring application a multipart request is typically serialized
by the FormHttpMessageConverter and hence the Content-Disposition is
not explicitly set by the application.
This commit adds the port information in the "Host" HTTP request header
for the Netty-based HTTP client.
Issue: SPR-15706
(cherry-picked from commit baaa84e90)
In the 4.3.x line, conversion exceptions do not get wrapped as RestClientException yet, so the expectation remains to receive a HttpMessageNotReadableException for conversion-level IOExceptions.
Issue: SPR-13592
Previously a requestURI that contained ';' would have the value incorrectly stripped out when using
ForwardedHeaderFilter.
This commit ensures that the ';' is preserved when using ForwardedHeaderFilter.
Issue: SPR-15428
Previously ForwardedHeaderFilter would override the requestURI with a URL decoded value. This would cause
problems when using a URL encoded requestURI since downstream Filters would not see the URL encoded
value as they should.
This commit resolves this issue by ensuring that the requestURI is properly encoded.
Issues SPR-15422
Previously ForwardedHeaderFilter would return the same StringBuffer for every invocation. This
meant that users that modified the StringBuffer changed the state of the HttpServletRequest.
This commit ensures that a new StringBuffer is always returned for ForwardedHeaderFilter.
Issue: SPR-15423
Prior to this commit, the `ShallowEtagHeaderFilter` could participate in
the response and set its ETag/Content-Length headers, even for HEAD
requests. Since the response body is empty, the filter implementation
would set a `"Content-Length: 0"`.
The RFC states that responses to HEAD requests should exhibit identical
response headers to GET (with the possible exception of payload related
headers such as Content-Length.
With this commit, `ShallowEtagHeaderFilter` now ignores HEAD requests
since the proper values may be set already for payload related headers
by the handler. The filter has no way to generate a proper ETag value
nor calculate the content length without the actual body.
Issue: SPR-15261
(cherry picked from commit b732251)
This commit checks that a "Content-Length" request header isn't already
present before adding one in `Netty4ClientHttpRequestFactory`.
`HttpMessageConverter` implementations can write that request header so
the Netty request factory should only write that value when the header
is missing.
If that header is not written (and since we're not dealing with
the HTTP exchange in a chunked-based fashion), the HTTP client might not
send the request body at all.
Issue: SPR-15241
This commit *adds* the "intercepted" headers to the ClientHttpRequest,
as opposed to replacing them, which is what happened before this commit.
Issue: SPR-15166
Prior to this commit, the `ResourceRegionHttpMessageConverter` would
rely on the default implementation of `getDefaultContentType` to guess
the default Content-Type of the resource region to be written to the
HTTP response. That implementation fetches the first media type
provided in the HTTP request "Accept" header.
This behavior is not correct when converting resources and this commits
aligns this converter with the `ResourceHttpMessageConverter` which uses
JAF to guess the correct Content-Type of the given resource, or just
returns "application/octet-stream" as a default value.
Issue: SPR-15041
Previously ForwrdedHeaderFilter did not ensure that
HttpServletResponse.sendRedirect worked properly based on
X-Forwarded-* headers.
This commit updates ForwardedHeaderFilter to overrided the
HttpServletResponse.sendRedirect method to ensure
X-Forwarded-* headers are honored.
Issue SPR-15020
This commit ensures that POST/PUT requests sent by the Netty client have
a Content-Length header set.
Integration tests have been refactored to use mockwebserver instead of
Jetty and have been parameterized to run on all available supported
clients.
Issue: SPR-14860
Cherry-picked from: ec8391a7fb
This commit aborts the HttpComponentsAsyncClientHttpRequest whenever the
returned Future is canceled.
Issue: SPR-14845
(cherry picked from commit 8f84446)
This commit fixes `NumberFormatException`s that were thrown when parsing
IPv6 host values in `X-Forwarded-Host` request headers.
Issue: SPR-14761
(cherry picked from ea5ff87f8e)
Rather than setting the status to 503 directly from the timeout
interceptor which no longer seems to work reliably with Servlet
containers like Jetty even performing an additional ERROR dispatch back
to the original URL, we know rather set the DeferredResult to an
AsyncTimeoutException, which results in a dispatch and standard
handling within Spring MVC. This should be a more reliable way of
dealing with timeouts.
Issue: SPR-14669
