Sebastien,
The answer depends on the particular HttpResponse.BodySubscriber/Handler
implementation
supplied to the sendAsync() call. Some of the simpler ones which return
aggregate/completed objects
like String, or byte[] do not appear to stream and the response body is
not returned until after all data has been read.
But, BodySubscribers and handlers can be designed to return the body
reading object any time after the response
headers have been received. One example is the
BodySubscriber<InputStream> which is another standard implementation
we provide. Obviously, in that case, the InputStream does not represent
the completely read body, but is just
an object used to read the body.
Note, the only difference between those two types of body subscriber is
when the object returned from
HttpResponse.body() becomes visible. In both cases, the data is streamed
to the subscriber object as it is
received and according to the normal flow control rules of the
j.u.concurrent.Flow API.
Hope this helps,
Michael.
On 05/04/2018, 11:07, Sebastien Deleuze wrote:
Hi,
I am currently implementing a draft support for JDK new HTTP client in
Spring Framework 5 [1] (using JDK 10 for now) in order to be able to
leverage it as a WebClient [2] engine.
Our integration tests all pass with regular HTTP/1.1 webservices (we
have not tested the HTTP/2 support yet), but not with streaming APIs.
Based on my current understanding, it seems
the CompletableFuture<HttpResponse> returned by HttpClient#sendAsync
completes only when all the data of the response body is available,
not asap the status code + headers are available like with Jetty or
Reactor Netty clients (which prevents to consume infinite streams via
Reactive Streams API).
Is consuming streaming HTTP/1.1 endpoints (like JSON streaming or SSE)
supported by current implementation?
Regards,
Sébastien Deleuze
[1] https://github.com/sdeleuze/jdk-http-webclient/
[2]
https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-client
