RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v9]

[Daniel Jeliński]

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/Finished.java line 852:

> 850:                     QuicTLSEngineImpl engine =
> 851:                             (QuicTLSEngineImpl) shc.conContext.transport;
> 852:                     engine.deriveOneRTTKeys();

We should not derive the server's 1RTT read keys before processing the client's Finished message.

Also, we could skip calculating the SSL WriteCipher when QUIC is in use. Also, we're calculating the baseWriteSecret twice (deriveOneRTTKeys calculates the same secret)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169636620