RFR: 8350451: HttpClient should not wait until the request body has been fully sent before reading the response headers

Volkan Yazici vyazici at openjdk.org
Fri Feb 21 13:21:04 UTC 2025


On Thu, 20 Feb 2025 18:44:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi - Please find here a PR that improves streaming strategy in the HttpClient.
> 
> The HttpClient currently waits until the full request body has been sent before starting to listen for a response. This is not optimal, in particular in cases where the server sends back e.g. 500 without even reading the body. It also prevents starting to stream the response body from the server before having sent the full request body, which prevents the server to stream back the request body to the client without reading it fully first.
> 
> While writing a test to verify the fix, I also noticed a few places where additional tasks needed to be performed asynchronously (= delegated to the executor) to support this.

test/jdk/java/net/httpclient/PostFromGetTest.java line 530:

> 528:      * the get response will pause before the connection window is filled.
> 529:      */
> 530:     static abstract class HTTPGetPostHandler implements HttpTestHandler {

This PR aims to enable reading response in parallel with sending the request body. Maybe naive of me, but... can we _only_ test this? That is,

1. Client uses a request body publisher that blocks waiting for a `responseBodyReceived` signal, and upon wake up, raises the `requestBodySent` flag
2. Server responds (payload can be a constant)
3. Client response body reader consumes the response and raises the `responseBodyReceived` flag (blocked request body publisher gets released)
4. Test waits on the `requestBodySent` flag
5. Test verifies the received response

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23716#discussion_r1965462392


More information about the net-dev mailing list