Use DataBufferUtils.compose instead of writeAggregator to combine
multiple data buffers into one, as the write aggregator would not work
when the initial data buffer did not have enough capacity to contain
all subsequent buffers.
Removed writeAggregator, as it is no longer needed.
Issue: SPR-16365
The match/matches methods of UriTemplate use a regex with (.*) in place
of URI variables, which work fine except in the end where such a
pattern can match greedily more than one segment.
This commit updates the regex to use ([^/]*) instead since URI
variables are only meant to be used within a single path segment.
Issue: SPR-16169
Optimize same origin check when the request is an instance of
ServletServerHttpRequest and when there is no forwarded headers.
This commit also optimizes the getPort methods and ForwardedHeaderFilter
forwarded headers checks.
Issue: SPR-16262
This commit refines forwarded protocol support in order to support
proxies that only set "X-Forwarded-Proto" header and not
"X-Forwarded-Port" by performing a reset of the port in such case.
"Forwarded" header support has been updated accordingly since it
also supports similar use case, as described in SPR-15504.
Issue: SPR-16262
Since type erasure can be fixed only when using
ParameterizedTypeReference based Java methods, RestOperations and
WebFlux API documentation should be updated to specify which extensions
are subject to type erasure, and which are not.
Issue: SPR-16273
This commit moves the ResolvableType field from HttpEntity to
PublisherEntity, a new entity type defined in MultipartBodyBuilder.
With this change, the scope of the ResolvableType is limited to
multipart-related code, instead of becoming part of the complete
HttpEntity hierarchy.
Issue: SPR-16307
This commit adds a ResolvableType field to HttpEntity, in order to
support Publishers as multipart data. Without the type, the
MultipartHttpMessageWriter does not know which delegate writer to use to
write the part.
Issue: SPR-16307
This commit allows CorsConfiguration#combine()
to differentiate permit default values set by
CorsConfiguration#applyPermitDefaultValues()
from values configured explicitly by the user.
Those permit default values will be overridden
by any user-provided ones while user-provided values
will be combined in an additive way, including
when "*" is specified.
Documentation has been improved accordingly.
Issue: SPR-15772
If the response is set and we can't change the status through
ServerHttpResponse any more, allow the error signal to propagate and
let the individual server adapters handle it. Ultimately that should
result in closing the connection.
On Servlet containers, we check one last time if the response is
committed (we may not have filled the buffer). If not then save
the exception as a request attribute, dispatch, and re-throw it on the
container thread.
On Undertow access the connection and close it.
On Netty just let the error through to Reactor Netty.
Issue: SPR-16051
Provide a fully mutable HttpHeaders to ClientHttpRequestInterceptors
of a RestTemplate when headers are set using HttpEntity. This avoids
UnsupportedOperationException if both HttpEntity and
ClientHttpRequestInterceptor add values for the same HTTP header.
Issue: SPR-15066
The request URI returned from HttpServerRequest.uri() typically
contains contains an absolute path but could also contain an
absolute URI. This commit adds handling for the latter, effectively
taking only the absolute path portion.
Issue: SPR-16243
ResponseStatusExceptionHandler lets the error through if it can't
change the status while HttpWebHandlerAdapter logs a more helpful
message (including status code) but without a full stack trace.
Issue: SPR-16231
1. setComplete checks the isCommitted flag to avoid an unnecessary
debug message. This method is meant to be safe to call many times.
2. setStatusCode lowers log message to TRACE, since the return value
communicates the outcome it's arguably much less critical.
3. Add comment and test case for ResponseStatusExceptionHandler.
A ResponseStatusException is clearly meant to be handled by this
handler so don't let it pass through even if the respones is
committed.
Issue: SPR-16231
Before this commit, the return value from write was interpreted as the
data being fully written and ready to be released via releaseData().
This is not true for WebSocketSession implementations where a true
return value simply means the message was sent with the full payload
but releas is not appropriate until a send confirmation.
Technically not an issue since WebSocketSession's extending this do
not use pooled buffers. Nevertheless this commit refines the semantics
of write, removes the releaseData() method, and makes sub-classes
responsible for releasing the buffer when fully written (and they
know best when that is). As a bonus currentData is now private.
Issue: SPR-16207
This commit turns suspendReading() into a readingPaused() notification
that is invoked after a succession of reads stops because there is no
more demand. Sub-classes can use this notification to suspend, if that
applies to them.
Most importantly the notification is guaranteed not to overlap with
checkOnDataAvailable() which means that suspend does not need to be
atomic and guarded against resume. The two can and do compete all the
time when reading ends with no demand, and a request for demand arrives
concurrently.
Issue: SPR-16207
Access-Control-Allow-Credentials CORS header, used to
allow cookies with CORS requests, is not set to true
anymore by default when enabling CORS with
@CrossOrigin or global CORS configuration in order to
provide a more secured default CORS configuration.
The related allowCredentials property now requires to
be set to true explicitly in order to support cookies
with CORS requests.
Issue: SPR-16130
Transition from DEMAND->NO_DEMAND:
Two concurrent threads enter DEMAND.request and DEMAND.onDataAvailable.
And DEMAND.onDataAvailable finishes before DEMAND.request to be able to
update the demand field then a request for reading will be lost.
Transition from READING->NO_DEMAND:
readAndPublish() returns false because there is no demand but before
switching the states READING.request is invoked again a request for
reading will be lost.
Changing READING->DEMAND/NO_DEMAND is made conditional so that the
operations will be executed only if changing states succeeds.
When in READING state detect completion before each next item in order
to exit sooner, if completed.
Issue: SPR-16207
Juergen Hoeller
Arjen Poutsma
Rossen Stoyanchev
Jeff Nelson
sdeleuze
Christoph Dreis
Sam Brannen
Violeta Georgieva