8335181: Incorrect handling of HTTP/2 GOAWAY frames in HttpClient

[ryanflegel]

I am backporting this fix because I am being affected by JDK-8335181. I had to downgrade to HTTP/1.1 in order to use HttpClient.

I needed to resolve two minor conflicts in MultiExchange.java due to JDK-8191494 being applied slightly differently in different projects. In both cases, I kept the change closer to upstream.

The conflicts were:

• Explicit vs implicit null field initialization
• Different debug log message

Tests

All tests in the GitHub actions have passed.

I have run the jdk/java/net tests locally and there were several failures, including 4 within java/net/httpclient. However, I have confirmed that all the failed tests also fail before applying the patch, so they seem to be unrelated.

Here is a full list of the failures:

• java/net/DatagramSocket/B6411513.java: java.net.DatagramSocket.receive: packet isn't received
• java/net/DatagramSocket/SendReceiveMaxSize.java: This test verifies that on macOS, the send buffer size is configured by default so that none of our implementations of the UDP protocol will fail with a "packet too large" exception when trying to send a packet of the maximum possible size allowed by the protocol.
• java/net/httpclient/ConnectTimeoutNoProxyAsync.java: Tests for connection related timeouts
• java/net/httpclient/ConnectTimeoutNoProxySync.java: Tests for connection related timeouts
• java/net/httpclient/ConnectTimeoutWithProxyAsync.java: Tests for connection related timeouts
• java/net/httpclient/ConnectTimeoutWithProxySync.java: Tests for connection related timeouts

UPDATE: I've run the rest of the tier2 tests and there were two additional JDK failures that appear to be unrelated:

• com/sun/jndi/dns/ConfigTests/Timeout.java: Tests that we can set the initial UDP timeout interval and the number of retries.
• com/sun/jndi/ldap/LdapPoolTimeoutTest.java: Multi-threaded client timeout tests for ldap pool

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8335181 needs maintainer approval

Issue

• JDK-8335181: Incorrect handling of HTTP/2 GOAWAY frames in HttpClient (Bug - P3)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk21u-dev.git pull/1020/head:pull/1020
$ git checkout pull/1020

Update a local copy of the PR:
$ git checkout pull/1020
$ git pull https://git.openjdk.org/jdk21u-dev.git pull/1020/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1020

View PR using the GUI difftool:
$ git pr show -t 1020

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk21u-dev/pull/1020.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back ryanflegel! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 02: Full (45945f63)
• 01: Full - Incremental (6d99ac77)
• 00: Full (1ac05af9)

[jaikiran]

Hello Ryan,

I was unable to run local tests due to this error:

* For target jdk__optimize_image_exec:
Error: Unable to initialize main class build.tools.jigsaw.AddPackagesAttribute
Caused by: java.lang.ClassFormatError: StackMapTable format error: access beyond the end of attribute

If you are on macosx and using Xcode 16 then I suspect you are running into the issue noted in https://mail.openjdk.org/pipermail/jdk-dev/2024-September/009400.html

[ryanflegel]

Thanks @jaikiran. That's almost certainly what the issue is. I'll downgrade to XCode 15.4 and give the tier2 tests another try.

[ryanflegel]

I was able to get tests running after downgrading XCode and have updated the PR description with the results.

[ryanflegel]

/label net

[openjdk]

@ryanflegel
The label net is not a valid label.
These labels are valid:

[ryanflegel]

Testing is complete for this PR and it is ready for review. Is there someone that can take a look?

[openjdk]

@ryanflegel this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout backport-720b44648b
git fetch https://git.openjdk.org/jdk21u-dev.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

[ryanflegel]

Merged from master to resolve some trivial merge conflicts.

Re-running tier2 tests, I only have the following failures:

• java/net/DatagramSocket/B6411513.java: java.net.DatagramSocket.receive: packet isn't received
• java/net/DatagramSocket/SendReceiveMaxSize.java: This test verifies that on macOS, the send buffer size is configured by default so that none of our implementations of the UDP protocol will fail with a "packet too large" exception when trying to send a packet of the maximum possible size allowed by the protocol.

[bridgekeeper]

@ryanflegel This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[ryanflegel]

Hi - just wondering if there's any chance of this being backported? As someone affected by JDK-8335181, I was hoping to see this fixed.

[jaikiran]

Hello Ryan, I don't follow the JDK updates project, so I can't say if/when this will be backported. However, the fix for the original issue is in JDK 24, which hasn't yet been released. So backporting this might be a bit too early at this point, especially since it isn't a regression (the issue has been present since Java 11). My opinion is that this is worth backporting but only after the fix has seen some usage in a GA version of Java 24 or beyond.