On Thu, 13 Aug 2026 03:43:22 GMT, Lee Jiwon <[email protected]> wrote:
>> test/jdk/java/net/httpclient/Http1RequestEmptyBufferTest.java line 95:
>>
>>> 93: throw new IOException("Unexpected EOF while reading
>>> terminal chunk");
>>> 94: } catch (SocketTimeoutException e) {
>>> 95: return terminalChunkCount;
>>
>> The caveat is that this test will always have to wait for
>> Utils.adjustTimeout(1000) before the full response is received. Well, I
>> guess that can't be helped.
>
> If the server sends `Connection: close` and the test reads until EOF, the
> response is no longer delayed by the socket timeout on the normal path.
> The timeout is still kept as a backstop.
>
> With the JDK-8308024 fix reverted, 20/20 runs failed with `got: 2`. With the
> fix in place, 30/30 runs passed.
>
> I haven't pushed this change yet. Would you prefer this approach?
Ah... do you mean sending the response (including Connection: close) after the
first empty chunk and then continue reading, but fail if a second chunk is
received before EOF?
If such a test reliably fails without the fix and pass with it, yes that could
be a better alternative!
IIRC the client should not close the connection before it has finished sending
the request. HTTP/1.1 doesn't have a way for the server to convey that it's not
interested in receiving the rest of the body (no RESET or STOP_SENDING like in
HTTP/2 or HTTP/3) - so the client should probably continue sending the request
body even if it has already received the full response. There could be bugs
though ;-) But if the test reliably fails without the fix we can get confidence
that the test is good enough for the fix. So yes - I think I would prefer the
new approach you're suggesting, thanks!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32209#discussion_r3774286459
