On Mon, 19 Oct 2026 13:35:32 GMT, Daniel Jeliński <[email protected]> wrote:
>> This fixes a regression introduced by >> [JDK-8317808](https://bugs.openjdk.org/browse/JDK-8317808). If the server >> sends all the response bytes, sends a GOAWAY, and immediately closes the >> connection since all streams are closed on its side, the client may fail to >> complete the request properly although all bytes have been received. >> Upon noticing that the connection is closed the client will interrupt all >> exchanges, even those for which all bytes have been received (but not yet >> pulled). >> >> This typically happens when the response body is delivered as an InputStream. >> >> The same issue also happens with HTTP/3. >> >> For HTTP/2 we will allow the BodySubscriber to continue pulling the bytes, >> unless we notice that the bodyCF is completed exceptionally. >> >> For HTTP/3 the logic is a bit different: when the connection is closed it >> forcefully terminates all exchanges. We will skip those exchange for which >> the underlying QUIC receiving stream state is DATA_READ or DATA_RCVD (and >> which are not blocked by QPack) >> >> Testing: >> >> A new scenario is added to >> test/jdk/java/net/httpclient/http2/H2GoAwayPromptConnectionClose.java to >> test the HTTP/2 changes. A new test is added for HTTP/3. >> >> Both tests fail without the fix and pass with it. Failure without the fix is >> not 100% guaranteed, but my experiments saw the tests reliably failing. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/java.net.http/share/classes/jdk/internal/net/http/Http3Connection.java > line 680: > >> 678: // Figure out whether this is an orderly close. >> 679: boolean orderlyClose = tc.isAppLayer() && tc.getCloseCode() == >> H3_NO_ERROR.code(); >> 680: if (orderlyClose) { > > IMO we shouldn't discard fully received responses even if the connection was > closed because of an error. It may result in different requests getting > different errors, but I think it's still better than throwing an error on an > exchange that completed correctly otherwise. Maybe. I believe we could consider it, but in that case I would prefer to do it as a follow-up fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33385#discussion_r4316706309
