On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfu...@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 616 commits: > > - merge latest changes from master branch > - merge latest http3 changes > - Hide internal classes > - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete > - quic: remove unused fields > - Make final fields static > - Remove unused variable > - merge latest changes from master branch > - http3: update summary in H3SimpleTest.java > - http3: review feedback - use copy() instead of > thenApply(Function.identity()) > - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9 I have updated the PR with commits that address most review feedback. Among the changes is also one that simplifies how opting in for HTTP/3 is handled. Before this change our implementation would employ different default strategies depending on whether HTTP/3 was set on the client or on the request. We decided to simplify this by handling the two in the same way: whether HTTP/3 is set on the client or on the request no longer matters, as long as it is set in one of them. In both cases - the strategy will be the same: if a new HTTP/3 connection is needed, the connection will be attempted as specified in Http3DiscoveryMode.ANY, unless a more specific H3_DISCOVERY option is explicitely set on the request. The corresponding API documentation / implNote in HttpOption.java have been updated accordingly. There's one sentence in the JEP that will also need to be updated to match this behaviour. The apidiff/specdiff attached to the CSR will also need to be updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-3206660010
