From djelinski at openjdk.org Mon Dec 1 08:56:02 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 1 Dec 2025 08:56:02 GMT Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures should be converted to ProtocolException [v5] In-Reply-To: References:

Message-ID: On Wed, 26 Nov 2025 10:39:20 GMT, Volkan Yazici wrote: >> Add guards against `HttpHeaders::firstValueAsLong` failures. `H3MalformedResponseTest` is overhauled ? migrated to JUnit, reinforced with exception type tests, etc. ? but not all `firstValueAsLong` changes are verified with new additional tests. `test/jdk/java/net/httpclient/` tests still do pass. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Introduce dangling `firstValueAsLong("content-length")` calls back Changes requested by dfuchs (Reviewer). src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 338: > 336: } catch (ProtocolException pe) { > 337: cf.completeExceptionally(pe); > 338: return cf; We're not going to read the body if we return here, so I think we should close the connection with the ProtocolException `pe` before returning the completable future `cf`. Otherwise - the connection will remained unclosed and out of the pool until we close the client. src/java.net.http/share/classes/jdk/internal/net/http/Http3Stream.java line 630: > 628: finalResponse = true; > 629: } else { > 630: assert responseCode >= 100 && responseCode <= 200 : "unexpected responseCode: " + responseCode; Can we keep the assert? ------------- PR Review: https://git.openjdk.org/jdk/pull/28431#pullrequestreview-3524324264 PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2576552862 PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2576571136 From djelinski at openjdk.org Mon Dec 1 10:56:02 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 1 Dec 2025 10:56:02 GMT Subject: RFR: 8372409: java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java timed out during warmup In-Reply-To: References: Message-ID: On Tue, 25 Nov 2025 14:38:01 GMT, Daniel Fuchs wrote: > The issue here occurs when the connection gets closed just before the `Http3ExchangeImpl` gets created. In that case the h3 stream reference counter gets incremented, but due to the connection being already closed Http3ExchangeImpl::close will not be invoked, even though the CF returned to the user has been correctly completed with the appropriate exception. Not calling `Http3ExchangeImpl::close` after the reference counter has been incremented prevents that reference counter from being properly decremented. This in turn causes `HttpClient::close()` to wait forever. > > The fix is to double-check that the connection is still open after having added the exchange to the connection's exchange map. If the connection is still opened, we can start the exchange. Otherwise we mark it as unprocessed and close it. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28494#pullrequestreview-3524368077 From djelinski at openjdk.org Mon Dec 1 11:03:15 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 1 Dec 2025 11:03:15 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v7] In-Reply-To: References:

Message-ID: On Mon, 24 Nov 2025 17:22:39 GMT, Matthew Donovan wrote: >> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. > > Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Updated IPAddressDNSIdentities and confirmed test fails for correct reason > - Merge branch 'master' into update-md5-certs > - Updated SAN methods in CertificateBuilder to take multiple names > - Merge branch 'master' into update-md5-certs > - removed IPIdentitites.java because it's identical to IPAddressIPIdenties; added IPv6 SAN ext > - removed unused keystore files, fixed certificate chain > - Merge branch 'master' into update-md5-certs > - changed line wrapping > - removed unnecessary comment and made getSSLContext(...) private > - changed tests to use SecurityUtils.removeDisabled*Algs methods > - ... and 3 more: https://git.openjdk.org/jdk/compare/d0629285...ea9c2dce Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27342#pullrequestreview-3524380076 From smonteith at openjdk.org Mon Dec 1 12:07:02 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Mon, 1 Dec 2025 12:07:02 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. Message-ID: MemorySegments allocated from shared Arena from java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | |---------|-------|-------|-------|-------|-------|-------| | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | After: | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | |---------|-------|-------|-------|-------|-------|-------| | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 | 16.52 | | 16 | 70.15 | 47.76 | 52.37 | 47.26 | 70.91 | 14.53 | | 24 | 77.38 | 78.14 | 81.67 | 71.98 | 87.20 | 21.70 | | 32 | 87.54 | 98.01 | 84.73 | 86.79 | 109.25 | 22.65 | | 48 | 121.54| 128.14 | 120.51 | 104.35 | 175.08 | 26.85 | ------------- Commit messages: - 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas Changes: https://git.openjdk.org/jdk/pull/28575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28575&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371260 Stats: 628 lines in 33 files changed: 402 ins; 38 del; 188 mod Patch: https://git.openjdk.org/jdk/pull/28575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28575/head:pull/28575 PR: https://git.openjdk.org/jdk/pull/28575 From mdonovan at openjdk.org Mon Dec 1 12:21:04 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 1 Dec 2025 12:21:04 GMT Subject: Integrated: 8353738: Update TLS unit tests to not use certificates with MD5 signatures In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan wrote: > This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. This pull request has now been integrated. Changeset: f5eecc45 Author: Matthew Donovan URL: https://git.openjdk.org/jdk/commit/f5eecc454eb78fc1a3714dfe3cb94113238dd3ac Stats: 3481 lines in 14 files changed: 402 ins; 2957 del; 122 mod 8353738: Update TLS unit tests to not use certificates with MD5 signatures Reviewed-by: djelinski, abarashev ------------- PR: https://git.openjdk.org/jdk/pull/27342 From dfuchs at openjdk.org Mon Dec 1 12:33:01 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 1 Dec 2025 12:33:01 GMT Subject: Integrated: 8372409: java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java timed out during warmup In-Reply-To: References: Message-ID: On Tue, 25 Nov 2025 14:38:01 GMT, Daniel Fuchs wrote: > The issue here occurs when the connection gets closed just before the `Http3ExchangeImpl` gets created. In that case the h3 stream reference counter gets incremented, but due to the connection being already closed Http3ExchangeImpl::close will not be invoked, even though the CF returned to the user has been correctly completed with the appropriate exception. Not calling `Http3ExchangeImpl::close` after the reference counter has been incremented prevents that reference counter from being properly decremented. This in turn causes `HttpClient::close()` to wait forever. > > The fix is to double-check that the connection is still open after having added the exchange to the connection's exchange map. If the connection is still opened, we can start the exchange. Otherwise we mark it as unprocessed and close it. This pull request has now been integrated. Changeset: 785ca67e Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/785ca67e46c762ed0ffaeda1e26e5f90276181e8 Stats: 26 lines in 2 files changed: 21 ins; 0 del; 5 mod 8372409: java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java timed out during warmup Reviewed-by: djelinski ------------- PR: https://git.openjdk.org/jdk/pull/28494 From alanb at openjdk.org Mon Dec 1 13:15:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 13:15:49 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... Can you confirm that you aren't planning to try to try to integrate this before the fork for JDK 26 this week? There are several discussion points, and some of the changes are in risky areas, will likely need back time in main line. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3596489652 From alanb at openjdk.org Mon Dec 1 13:20:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 13:20:49 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 396: > 394: private final PendingFuture result; > 395: private volatile boolean released; > 396: private int ticket; // to release buffer scope This is for substitution, so needs to be declared with buf (further down), and needs to be volatile (can't use plain access as it may be released on different thread). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2577021290 From smonteith at openjdk.org Mon Dec 1 13:48:47 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Mon, 1 Dec 2025 13:48:47 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References:

Message-ID: <49FGQkAhjaiL3NugHvEzFGQhwTOf1oOKIPAUihJDgF0=.f19c5f9b-fa41-4fbe-9223-cba043dfa1d0@github.com> On Mon, 1 Dec 2025 13:13:13 GMT, Alan Bateman wrote: > Can you confirm that you aren't planning to try to try to integrate this before the fork for JDK 26 this week? There are several discussion points, and some of the changes are in risky areas, will likely need back time in main line. I am not planning, and wouldn't want to integrate this just before a fork. While I've checked it the best I can, I'd appreciate some scrutiny. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3596636408 From schernyshev at openjdk.org Mon Dec 1 14:22:03 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 1 Dec 2025 14:22:03 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException Message-ID: Hi all, Let me propose a fix and a test case for JDK-8369950. The failure reproduces with BCJSSE provider and all implementations of SSLSocker other than SSLSocketImpl. In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. SNIHostName, as defined in https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. This mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 Testing: - standard jtreg tests goups showed no regressions - the new test passes with the fix and fails otherwise - passes also with BCJSSE in FIPS and standard mode

BCJSSE standard

STDOUT: STDERR: Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty INFORMATION: Found boolean security property [keystore.type.compat]: true Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': dsa_sha1 usage HandshakeSignature Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty INFORMATION: Found string security property [jdk.certpath.disabledAlgorithms]: MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 usage SignedJAR & denyAfter 2019-01-01 Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create WARNUNG: Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 jdkCA & usage TLSServer Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create WARNUNG: Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 usage SignedJAR & denyAfter 2019-01-01 Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSystemProperty INFORMATION: Found string system property [java.home]: /Users/sercher/repos/jdk/build/macosx-x86_64-server-release/images/jdk Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyHandshakeBeginning INFORMATION: [server #1 @193b6d73] accepting connection from 0:0:0:0:0:0:0:1:56197 Dez. 01, 2025 2:44:03 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyHandshakeComplete INFORMATION: [server #1 @193b6d73] established connection with 0:0:0:0:0:0:0:1:56197 Dez. 01, 2025 2:44:08 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyConnectionClosed INFORMATION: [server #1 @193b6d73] disconnected from 0:0:0:0:0:0:0:1:56197 STATUS:Passed.

BCJSSE FIPS

STDOUT: STDERR: Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty INFORMATION: Found boolean security property [keystore.type.compat]: true Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': dsa_sha1 usage HandshakeSignature Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty INFORMATION: Found string security property [jdk.certpath.disabledAlgorithms]: MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 usage SignedJAR & denyAfter 2019-01-01 Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create WARNUNG: Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 jdkCA & usage TLSServer Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create WARNUNG: Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 usage SignedJAR & denyAfter 2019-01-01 Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSystemProperty INFORMATION: Found string system property [java.home]: /Users/sercher/repos/jdk/build/macosx-x86_64-server-release/images/jdk Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyHandshakeBeginning INFORMATION: [server #1 @4d1e9767] accepting connection from 0:0:0:0:0:0:0:1:56184 Dez. 01, 2025 2:41:32 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyHandshakeComplete INFORMATION: [server #1 @4d1e9767] established connection with 0:0:0:0:0:0:0:1:56184 Dez. 01, 2025 2:41:37 PM org.bouncycastle.jsse.provider.ProvTlsServer notifyConnectionClosed INFORMATION: [server #1 @4d1e9767] disconnected from 0:0:0:0:0:0:0:1:56184 STATUS:Passed.

------------- Commit messages: - 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException Changes: https://git.openjdk.org/jdk/pull/28577/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28577&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369950 Stats: 404 lines in 2 files changed: 403 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28577.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28577/head:pull/28577 PR: https://git.openjdk.org/jdk/pull/28577 From djelinski at openjdk.org Mon Dec 1 14:38:20 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 1 Dec 2025 14:38:20 GMT Subject: RFR: 8366578: Remove the field tagSize in various QuicPacketEncoder.OutgoingQuicPacket subclasses Message-ID: Remove unused tagSize fields. Testing clean. ------------- Commit messages: - remove unused tagSize fields Changes: https://git.openjdk.org/jdk/pull/28578/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28578&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366578 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28578.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28578/head:pull/28578 PR: https://git.openjdk.org/jdk/pull/28578 From jpai at openjdk.org Mon Dec 1 14:49:35 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 14:49:35 GMT Subject: RFR: 8366578: Remove the field tagSize in various QuicPacketEncoder.OutgoingQuicPacket subclasses In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:19:39 GMT, Daniel Jeli?ski wrote: > Remove unused tagSize fields. Testing clean. Looks good and trivial to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28578#pullrequestreview-3525372413 From dfuchs at openjdk.org Mon Dec 1 15:20:36 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 1 Dec 2025 15:20:36 GMT Subject: RFR: 8366578: Remove the field tagSize in various QuicPacketEncoder.OutgoingQuicPacket subclasses In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:19:39 GMT, Daniel Jeli?ski wrote: > Remove unused tagSize fields. Testing clean. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28578#pullrequestreview-3525551935 From djelinski at openjdk.org Mon Dec 1 17:10:51 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 1 Dec 2025 17:10:51 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev wrote: > Hi all, > > Let me propose a fix and a test case for JDK-8369950. > > The failure reproduces with BCJSSE provider and all implementations of SSLSocker other than SSLSocketImpl. > > In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). > > The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. > > SNIHostName, as defined in > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 > > has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. > > This mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see > > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 > > Testing: > - standard jtreg tests goups showed no regressions > - the new test passes with the fix and fails otherwise > - passes also with BCJSSE in FIPS and standard mode > >

BCJSSE standard

> > > STDOUT: > STDERR: > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty > INFORMATION: Found boolean security property [keystore.type.compat]: true > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty > INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44... LGTM. Thanks! ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28577#pullrequestreview-3526098687 From dfuchs at openjdk.org Mon Dec 1 17:19:31 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 1 Dec 2025 17:19:31 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException In-Reply-To: References: Message-ID: <7AkGXks9t4bapk0cGxAcBvIYE5wN6ChDCDoG-gvOBGI=.0aee1a66-4ba2-4dcb-b22a-2b699b1544bd@github.com> On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev wrote: > Hi all, > > Let me propose a fix and a test case for JDK-8369950. > > The failure reproduces with BCJSSE provider and all implementations of SSLSocker other than SSLSocketImpl. > > In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). > > The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. > > SNIHostName, as defined in > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 > > has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. > > This mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see > > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 > > Testing: > - standard jtreg tests goups showed no regressions > - the new test passes with the fix and fails otherwise > - passes also with BCJSSE in FIPS and standard mode > >

BCJSSE standard

Message-ID: On Mon, 1 Dec 2025 17:08:26 GMT, Daniel Jeli?ski wrote: > LGTM. Thanks! @djelinski Thank you for review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3597970287 From schernyshev at openjdk.org Mon Dec 1 17:47:48 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 1 Dec 2025 17:47:48 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException In-Reply-To: <7AkGXks9t4bapk0cGxAcBvIYE5wN6ChDCDoG-gvOBGI=.0aee1a66-4ba2-4dcb-b22a-2b699b1544bd@github.com> References: <7AkGXks9t4bapk0cGxAcBvIYE5wN6ChDCDoG-gvOBGI=.0aee1a66-4ba2-4dcb-b22a-2b699b1544bd@github.com> Message-ID: On Mon, 1 Dec 2025 17:16:07 GMT, Daniel Fuchs wrote: > Please make sure to run tier2 before integrating. @dfuch Thanks Daniel. The new test is in tier2, so far it passes in macOS and Linux. Windows takes more time with tier2... ------------- PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3597983722 From djelinski at openjdk.org Mon Dec 1 17:57:58 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 1 Dec 2025 17:57:58 GMT Subject: RFR: 8368093: Remove Stream::createPseudoHeaders Message-ID: The method was copied to Utils, and all uses were updated. Remove the method now. The methods are still [identical](https://github.com/openjdk/jdk/blob/6cb1c8f9cfcb797af788ca8fb490f388cc68f525/src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java#L1326-L1354). Tests continue to pass. ------------- Commit messages: - Remove Stream::createPseudoHeaders Changes: https://git.openjdk.org/jdk/pull/28583/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28583&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368093 Stats: 31 lines in 1 file changed: 0 ins; 31 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28583.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28583/head:pull/28583 PR: https://git.openjdk.org/jdk/pull/28583 From mcimadamore at openjdk.org Mon Dec 1 18:26:47 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 1 Dec 2025 18:26:47 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... Thanks for working on this problem. At the high level I understand your goal here. It is a bit unfortunate that we have to change the API for acquire/release which cascades in many smaller (but simple) changes throughout the JDK. But let's set that aside. The main (and more serious) issue with this PR is the decoupling of the liveness bit from the ref counting part. This is something that will require some time to work through to ensure correctness is preserved in all cases. More generally, it is generally advisable for such deep changes to perhaps reach out to panama-dev mailing list first, and maybe have a discussion/reach some consensus there, before moving ahead with a PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3598181959 From smonteith at openjdk.org Mon Dec 1 19:06:46 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Mon, 1 Dec 2025 19:06:46 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References:

Message-ID: On Mon, 1 Dec 2025 18:24:07 GMT, Maurizio Cimadamore wrote: > Thanks for working on this problem. > > At the high level I understand your goal here. It is a bit unfortunate that we have to change the API for acquire/release which cascades in many smaller (but simple) changes throughout the JDK. But let's set that aside. Yes, that was regrettable. Originally I retained the "void release0()" that recalculated the "ticket", which resulted in fewer changes. However, it was felt the explicit ticket passing was less likely to introduce errors. > > The main (and more serious) issue with this PR is the decoupling of the liveness bit from the ref counting part. This is something that will require some time to work through to ensure correctness is preserved in all cases. > Yes, I had been grappling with the atomicity. The "acquireCount" and "state" are decoupled in the most recent revision of the, so this closing should either fail and not update state, or pass and complete the shutdown. However, the "state" and ScopedAccesses are complex, so I appreciate the scrutiny in that area. > More generally, it is generally advisable for such deep changes to perhaps reach out to panama-dev mailing list first, and maybe have a discussion/reach some consensus there, before moving ahead with a PR. That was my mistake - I expected that with the foreign ABI being merged, discussions on internals would have reverted to here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3598403208 From dfuchs at openjdk.org Mon Dec 1 20:00:55 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 1 Dec 2025 20:00:55 GMT Subject: RFR: 8368093: Remove Stream::createPseudoHeaders In-Reply-To: References: Message-ID: <3RDuGWdUtwkVA2gNgiS3urlx-kmyBh6F_nb94OfW2Tw=.b51fda84-ac5c-4712-aaff-bcc95dbd5416@github.com> On Mon, 1 Dec 2025 17:45:53 GMT, Daniel Jeli?ski wrote: > The method was copied to Utils, and all uses were updated. Remove the method now. > > The methods are still [identical](https://github.com/openjdk/jdk/blob/6cb1c8f9cfcb797af788ca8fb490f388cc68f525/src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java#L1326-L1354). Tests continue to pass. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28583#pullrequestreview-3526724716 From dfuchs at openjdk.org Mon Dec 1 20:03:48 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 1 Dec 2025 20:03:48 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev wrote: > Hi all, > > Let me propose a fix and a test case for JDK-8369950. > > The failure reproduces with BCJSSE provider and all implementations of SSLSocker other than SSLSocketImpl. > > In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). > > The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. > > SNIHostName, as defined in > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 > > has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. > > The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see > > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 > > Testing: > - standard jtreg tests goups showed no regressions > - the new test passes with the fix and fails otherwise > - passes also with BCJSSE in FIPS and standard mode > >

BCJSSE standard

> > > STDOUT: > STDERR: > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty > INFORMATION: Found boolean security property [keystore.type.compat]: true > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty > INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2... Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28577#pullrequestreview-3526733114 From jpai at openjdk.org Tue Dec 2 06:27:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 06:27:53 GMT Subject: RFR: 8368093: Remove Stream::createPseudoHeaders In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 17:45:53 GMT, Daniel Jeli?ski wrote: > The method was copied to Utils, and all uses were updated. Remove the method now. > > The methods are still [identical](https://github.com/openjdk/jdk/blob/6cb1c8f9cfcb797af788ca8fb490f388cc68f525/src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java#L1326-L1354). Tests continue to pass. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28583#pullrequestreview-3528354826 From duke at openjdk.org Tue Dec 2 08:33:47 2025 From: duke at openjdk.org (duke) Date: Tue, 2 Dec 2025 08:33:47 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev wrote: > Hi all, > > Let me propose a fix and a test case for JDK-8369950. > > The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. > > In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). > > The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. > > SNIHostName, as defined in > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 > > has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. > > The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see > > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 > > Testing: > - standard jtreg tests goups showed no regressions > - the new test passes with the fix and fails otherwise > - passes also with BCJSSE in FIPS and standard mode > >

BCJSSE standard

> > > STDOUT: > STDERR: > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty > INFORMATION: Found boolean security property [keystore.type.compat]: true > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty > INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2... @sercher Your change (at version 7d1a90321450ac9a875ba78c8f261f1729fdd524) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3600827920 From jpai at openjdk.org Tue Dec 2 09:19:06 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 09:19:06 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev wrote: > Hi all, > > Let me propose a fix and a test case for JDK-8369950. > > The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. > > In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). > > The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. > > SNIHostName, as defined in > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 > > has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. > > The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see > > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 > > Testing: > - standard jtreg tests goups showed no regressions > - the new test passes with the fix and fails otherwise > - passes also with BCJSSE in FIPS and standard mode > >

BCJSSE standard

> > > STDOUT: > STDERR: > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty > INFORMATION: Found boolean security property [keystore.type.compat]: true > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty > INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2... Hello Sergey, the copyright year on `HttpsClient` will need an update from `2001, 2024,` to `2001, 2025,` ------------- PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3601015803 From jpai at openjdk.org Tue Dec 2 09:32:06 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 09:32:06 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev wrote: > Hi all, > > Let me propose a fix and a test case for JDK-8369950. > > The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. > > In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). > > The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. > > SNIHostName, as defined in > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 > > has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. > > The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see > > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 > > Testing: > - standard jtreg tests goups showed no regressions > - the new test passes with the fix and fails otherwise > - passes also with BCJSSE in FIPS and standard mode > >

BCJSSE standard

> > > STDOUT: > STDERR: > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty > INFORMATION: Found boolean security property [keystore.type.compat]: true > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty > INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2... src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 478: > 476: !IPAddressUtil.isIPv4LiteralAddress(host) && > 477: !(host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']' && > 478: IPAddressUtil.isIPv6LiteralAddress(host.substring(1, host.length() - 1)) The `host` value here comes from `URL.getHost()` which specifies that it returns an IPv6 address enclosed in `[]`brackets. So what you have here looks fine to me. One additional thing I would suggest is to make this `protected String host` field of this class `final`. It currently gets assigned in the constructor of the `HttpClient` and `HttpsClient` and making this `final` would give an extra assurance that its value will always be coming from `URL.getHost()` call. These 2 `sun.net.www.http.HttpClient` and `HttpsClient` classes are internal to the JDK, so changing this protected field to final shouldn't cause any issues for application code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580356484 From jpai at openjdk.org Tue Dec 2 09:49:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 09:49:51 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev wrote: > Hi all, > > Let me propose a fix and a test case for JDK-8369950. > > The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. > > In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). > > The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. > > SNIHostName, as defined in > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 > > has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. > > The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see > > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 > > Testing: > - standard jtreg tests goups showed no regressions > - the new test passes with the fix and fails otherwise > - passes also with BCJSSE in FIPS and standard mode > >

BCJSSE standard

> > > STDOUT: > STDERR: > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty > INFORMATION: Found boolean security property [keystore.type.compat]: true > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty > INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2... test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 28: > 26: * @bug 8369950 > 27: * @library /test/lib > 28: * @summary TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException Nit - as per the jtreg tag order recommendation, the `@summary` should come before the `@library` https://openjdk.org/jtreg/tag-spec.html#ORDER test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 71: > 69: * currently 3 minutes by default, but you might try to be > 70: * smart about it.... > 71: */ I am not too familiar with these style of tests, but it looks like there are several similar ones in the `javax/net/ssl` area. Would you know if these comments are still accurate and up to date? In other words, do we need these comments in this test? test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 97: > 95: bw.write("HTTP/1.1 200 OK\r\n\r\n\r\n"); > 96: bw.flush(); > 97: Thread.sleep(5000); Is the sleep() necessary for this test? test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 165: > 163: */ > 164: SubjectAltNameIPv6() throws Exception { > 165: if (separateServerThread) { Are these if/else blocks needed or could we simplify the test to just expect the server and client to run as separate threads? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580413566 PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580386092 PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580387059 PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580393762 From jpai at openjdk.org Tue Dec 2 09:49:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 09:49:52 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 09:45:11 GMT, Jaikiran Pai wrote: >> Hi all, >> >> Let me propose a fix and a test case for JDK-8369950. >> >> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. >> >> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). >> >> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. >> >> SNIHostName, as defined in >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 >> >> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. >> >> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see >> >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 >> >> Testing: >> - standard jtreg tests goups showed no regressions >> - the new test passes with the fix and fails otherwise >> - passes also with BCJSSE in FIPS and standard mode >> >>

BCJSSE standard

Message-ID: On Tue, 2 Dec 2025 09:37:05 GMT, Jaikiran Pai wrote: >> Hi all, >> >> Let me propose a fix and a test case for JDK-8369950. >> >> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. >> >> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). >> >> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. >> >> SNIHostName, as defined in >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 >> >> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. >> >> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see >> >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 >> >> Testing: >> - standard jtreg tests goups showed no regressions >> - the new test passes with the fix and fails otherwise >> - passes also with BCJSSE in FIPS and standard mode >> >>

BCJSSE standard

Message-ID: On Tue, 2 Dec 2025 09:42:19 GMT, Daniel Jeli?ski wrote: >> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 71: >> >>> 69: * currently 3 minutes by default, but you might try to be >>> 70: * smart about it.... >>> 71: */ >> >> I am not too familiar with these style of tests, but it looks like there are several similar ones in the `javax/net/ssl` area. Would you know if these comments are still accurate and up to date? In other words, do we need these comments in this test? > > Let's clean this up in a follow-up PR. There's 60+ files with the same comment. Yes, doing this as a separate PR is fine with me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580437023 From jpai at openjdk.org Tue Dec 2 09:58:19 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 09:58:19 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 09:39:24 GMT, Jaikiran Pai wrote: >> Hi all, >> >> Let me propose a fix and a test case for JDK-8369950. >> >> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. >> >> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). >> >> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. >> >> SNIHostName, as defined in >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 >> >> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. >> >> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see >> >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 >> >> Testing: >> - standard jtreg tests goups showed no regressions >> - the new test passes with the fix and fails otherwise >> - passes also with BCJSSE in FIPS and standard mode >> >>

BCJSSE standard

Message-ID: On Tue, 2 Dec 2025 09:16:48 GMT, Jaikiran Pai wrote: > Hello Sergey, the copyright year on `HttpsClient` will need an update from `2001, 2024,` to `2001, 2025,` Thanks @jaikiran. That's correct. I will update the headers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3601305090 From djelinski at openjdk.org Tue Dec 2 12:18:04 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 2 Dec 2025 12:18:04 GMT Subject: RFR: 8366578: Remove the field tagSize in various QuicPacketEncoder.OutgoingQuicPacket subclasses In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:19:39 GMT, Daniel Jeli?ski wrote: > Remove unused tagSize fields. Testing clean. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28578#issuecomment-3601720908 From djelinski at openjdk.org Tue Dec 2 12:18:04 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 2 Dec 2025 12:18:04 GMT Subject: Integrated: 8366578: Remove the field tagSize in various QuicPacketEncoder.OutgoingQuicPacket subclasses In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:19:39 GMT, Daniel Jeli?ski wrote: > Remove unused tagSize fields. Testing clean. This pull request has now been integrated. Changeset: 13e062e7 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/13e062e7a36cf9880416a4e867de13778c6bed2b Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod 8366578: Remove the field tagSize in various QuicPacketEncoder.OutgoingQuicPacket subclasses Reviewed-by: jpai, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/28578 From djelinski at openjdk.org Tue Dec 2 12:19:03 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 2 Dec 2025 12:19:03 GMT Subject: RFR: 8368093: Remove Stream::createPseudoHeaders In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 17:45:53 GMT, Daniel Jeli?ski wrote: > The method was copied to Utils, and all uses were updated. Remove the method now. > > The methods are still [identical](https://github.com/openjdk/jdk/blob/6cb1c8f9cfcb797af788ca8fb490f388cc68f525/src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java#L1326-L1354). Tests continue to pass. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28583#issuecomment-3601722171 From djelinski at openjdk.org Tue Dec 2 12:19:05 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 2 Dec 2025 12:19:05 GMT Subject: Integrated: 8368093: Remove Stream::createPseudoHeaders In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 17:45:53 GMT, Daniel Jeli?ski wrote: > The method was copied to Utils, and all uses were updated. Remove the method now. > > The methods are still [identical](https://github.com/openjdk/jdk/blob/6cb1c8f9cfcb797af788ca8fb490f388cc68f525/src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java#L1326-L1354). Tests continue to pass. This pull request has now been integrated. Changeset: 5cba2c84 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/5cba2c8461005f2f7bcafdce622126a113f4bbd4 Stats: 31 lines in 1 file changed: 0 ins; 31 del; 0 mod 8368093: Remove Stream::createPseudoHeaders Reviewed-by: dfuchs, jpai, vyazici ------------- PR: https://git.openjdk.org/jdk/pull/28583 From schernyshev at openjdk.org Tue Dec 2 14:29:34 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 2 Dec 2025 14:29:34 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References: Message-ID: > Hi all, > > Let me propose a fix and a test case for JDK-8369950. > > The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. > > In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). > > The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. > > SNIHostName, as defined in > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 > > has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. > > The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see > > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 > > Testing: > - standard jtreg tests goups showed no regressions > - the new test passes with the fix and fails otherwise > - passes also with BCJSSE in FIPS and standard mode > >

BCJSSE standard

> > > STDOUT: > STDERR: > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty > INFORMATION: Found boolean security property [keystore.type.compat]: true > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty > INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature > Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create > WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': ecdsa_sha1 usage HandshakeSignature > Dez. 01, 2025 2... Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: - addressed more review comments - addressed review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28577/files - new: https://git.openjdk.org/jdk/pull/28577/files/7d1a9032..c388c253 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28577&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28577&range=00-01 Stats: 113 lines in 2 files changed: 17 ins; 69 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/28577.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28577/head:pull/28577 PR: https://git.openjdk.org/jdk/pull/28577 From dfuchs at openjdk.org Tue Dec 2 14:29:36 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 2 Dec 2025 14:29:36 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:12:04 GMT, Sergey Chernyshev wrote: > Hi all, > > Let me propose a fix and a test case for JDK-8369950. > > The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. > > In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). > > The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. > > SNIHostName, as defined in > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 > > has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. > > The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see > > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 > > Testing: > - standard jtreg tests goups showed no regressions > - the new test passes with the fix and fails otherwise > - passes also with BCJSSE in FIPS and standard mode > >

BCJSSE standard

Message-ID: On Tue, 2 Dec 2025 10:23:53 GMT, Sergey Chernyshev wrote: >> Hello Sergey, the copyright year on `HttpsClient` will need an update from `2001, 2024,` to `2001, 2025,` > >> Hello Sergey, the copyright year on `HttpsClient` will need an update from `2001, 2024,` to `2001, 2025,` > > Thanks @jaikiran. That's correct. I will update the headers. > @sercher did you intend to put this PR back into DRAFT? it had already the "sponsor" label when more reviews came. I changed to draft intentionally so no one would sponsor by mistake. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3602161053 From vyazici at openjdk.org Tue Dec 2 14:29:41 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Dec 2025 14:29:41 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 14:25:36 GMT, Sergey Chernyshev wrote: >> Hi all, >> >> Let me propose a fix and a test case for JDK-8369950. >> >> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. >> >> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). >> >> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. >> >> SNIHostName, as defined in >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 >> >> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. >> >> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see >> >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 >> >> Testing: >> - standard jtreg tests goups showed no regressions >> - the new test passes with the fix and fails otherwise >> - passes also with BCJSSE in FIPS and standard mode >> >>

BCJSSE standard

Message-ID: On Tue, 2 Dec 2025 11:14:19 GMT, Volkan Yazici wrote: >> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: >> >> - addressed more review comments >> - addressed review comments > > src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 476: > >> 474: // host has been set previously for SSLSocketImpl >> 475: if (!(s instanceof SSLSocketImpl) && >> 476: !IPAddressUtil.isIPv4LiteralAddress(host) && > > This introduces a new behavior for both IPv4 and IPv6, yet we only verify the IPv6 behavior. Shouldn't we also verify that when the provided host is an IPv4 literal, `setServerNames()` is left untouched? @vy The test excercises the same code path as in the BCJSSE case, that throws an exception on non-LDH symbols. Segments of IPv4 literal adresses are all LDH, so they do not trigger any exception. Adding an IPAddressUtil.isIPv4LiteralAddress() check in the above condition is purely to mirror SSLSocketImpl behavior, as I thought initially. On the other hand, should we then add a negative test with a certificate that doesn't have a SAN extension (or the 127.0.0.1 ipv4 address in it), that should fail in the HostnameVerifier when the 'https://127.0.0.1' is requested? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580917249 From schernyshev at openjdk.org Tue Dec 2 14:29:44 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 2 Dec 2025 14:29:44 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: <5Xi3KzSpKO5zUPBdESbgG7zc7JQmTjwjWgyVxiqN3Ic=.2464c8db-275e-43b7-9893-4c7cefac9f0e@github.com> On Tue, 2 Dec 2025 12:15:36 GMT, Sergey Chernyshev wrote: >> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 476: >> >>> 474: // host has been set previously for SSLSocketImpl >>> 475: if (!(s instanceof SSLSocketImpl) && >>> 476: !IPAddressUtil.isIPv4LiteralAddress(host) && >> >> This introduces a new behavior for both IPv4 and IPv6, yet we only verify the IPv6 behavior. Shouldn't we also verify that when the provided host is an IPv4 literal, `setServerNames()` is left untouched? > > @vy The test excercises the same code path as in the BCJSSE case, that throws an exception on non-LDH symbols. Segments of IPv4 literal adresses are all LDH, so they do not trigger any exception. Adding an IPAddressUtil.isIPv4LiteralAddress() check in the above condition is purely to mirror SSLSocketImpl behavior, as I thought initially. > > On the other hand, should we then add a negative test with a certificate that doesn't have a SAN extension (or the 127.0.0.1 ipv4 address in it), that should fail in the HostnameVerifier when the 'https://127.0.0.1' is requested? @djelinski would you think such a negative test is needed here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581325563 From schernyshev at openjdk.org Tue Dec 2 14:29:45 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 2 Dec 2025 14:29:45 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 09:29:01 GMT, Jaikiran Pai wrote: >> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: >> >> - addressed more review comments >> - addressed review comments > > src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 478: > >> 476: !IPAddressUtil.isIPv4LiteralAddress(host) && >> 477: !(host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']' && >> 478: IPAddressUtil.isIPv6LiteralAddress(host.substring(1, host.length() - 1)) > > The `host` value here comes from `URL.getHost()` which specifies that it returns an IPv6 address enclosed in `[]`brackets. So what you have here looks fine to me. > > One additional thing I would suggest is to make this `protected String host` field of this class `final`. It currently gets assigned in the constructor of the `HttpClient` and `HttpsClient` and making this `final` would give an extra assurance that its value will always be coming from `URL.getHost()` call. > > These 2 `sun.net.www.http.HttpClient` and `HttpsClient` classes are internal to the JDK, so changing this protected field to final shouldn't cause any issues for application code. @jaikiran I think this deserves a separate issue. I could file a bug for this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580621085 From jpai at openjdk.org Tue Dec 2 14:29:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 14:29:46 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 10:42:02 GMT, Sergey Chernyshev wrote: >> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 478: >> >>> 476: !IPAddressUtil.isIPv4LiteralAddress(host) && >>> 477: !(host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']' && >>> 478: IPAddressUtil.isIPv6LiteralAddress(host.substring(1, host.length() - 1)) >> >> The `host` value here comes from `URL.getHost()` which specifies that it returns an IPv6 address enclosed in `[]`brackets. So what you have here looks fine to me. >> >> One additional thing I would suggest is to make this `protected String host` field of this class `final`. It currently gets assigned in the constructor of the `HttpClient` and `HttpsClient` and making this `final` would give an extra assurance that its value will always be coming from `URL.getHost()` call. >> >> These 2 `sun.net.www.http.HttpClient` and `HttpsClient` classes are internal to the JDK, so changing this protected field to final shouldn't cause any issues for application code. > > @jaikiran I think this deserves a separate issue. I could file a bug for this. Yes, it's OK with me if you don't change this field to `final` in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580627052 From dfuchs at openjdk.org Tue Dec 2 14:29:48 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 2 Dec 2025 14:29:48 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 10:45:10 GMT, Volkan Yazici wrote: >> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: >> >> - addressed more review comments >> - addressed review comments > > src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 478: > >> 476: !IPAddressUtil.isIPv4LiteralAddress(host) && >> 477: !(host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']' && >> 478: IPAddressUtil.isIPv6LiteralAddress(host.substring(1, host.length() - 1)) > > There is one more place in `sun.net.www`, which is in this very class, that > > > (host.charAt(0) == '[' && host.charAt(host.length() - 1) == ']') { return host.substring(1, host.length() - 1) > > > logic is practiced. Would it make sense to refactor this into a `private static Optional ipv6FromHost(String host)` method, preferably with some short explanation in the method's Javadoc on why we do this? The same thought occurred to me but I'd rather keep refactoring at a minimum in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581000260 From schernyshev at openjdk.org Tue Dec 2 14:29:50 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 2 Dec 2025 14:29:50 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 09:47:21 GMT, Jaikiran Pai wrote: >> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 28: >> >>> 26: * @bug 8369950 >>> 27: * @library /test/lib >>> 28: * @summary TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException >> >> Nit - as per the jtreg tag order recommendation, the `@summary` should come before the `@library` https://openjdk.org/jtreg/tag-spec.html#ORDER > > Also, this test doesn't exercise the BouncyCastle provider. Would it be better to change this line to say: > > > @summary Test that the HttpsURLConnection does not set IPv6 address literals for SNI hostname during TLS handshake > Nit - as per the jtreg tag order recommendation, the `@summary` should come before the `@library` https://openjdk.org/jtreg/tag-spec.html#ORDER Thanks @jaikiran , i will update the order and the summary text. The BouncyCastle came here from the title of the issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580611708 From myankelevich at openjdk.org Tue Dec 2 14:29:52 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 2 Dec 2025 14:29:52 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

BCJSSE standard

Message-ID: On Tue, 2 Dec 2025 12:30:21 GMT, Mikhail Yankelevich wrote: >> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: >> >> - addressed more review comments >> - addressed review comments > > test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 32: > >> 30: */ >> 31: >> 32: import javax.net.ssl.*; > > nit: wildcard imports Thanks @myankelev . Done. > test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 50: > >> 48: * Turn on SSL debugging? >> 49: */ >> 50: static boolean debug = false; > > Could you please change this to be a env variable? something like > ```java > static boolean debug = Boolean.getBoolean("test.debug"); Thanks @myankelev . Accepted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581412259 PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581412017 From schernyshev at openjdk.org Tue Dec 2 14:29:56 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 2 Dec 2025 14:29:56 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 09:51:49 GMT, Jaikiran Pai wrote: >> Let's clean this up in a follow-up PR. There's 60+ files with the same comment. > > Yes, doing this as a separate PR is fine with me. @jaikiran Let me clean up the comments that are not anymore accurate in this particular PR. I personally try to avoid this type of changes that only touch the whitespace or comments blocks, including the copyright header ones, because they increase the number of connections between unrelated changes, that makes the fix less portable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580598800 From jpai at openjdk.org Tue Dec 2 14:29:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 14:29:57 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 10:34:57 GMT, Sergey Chernyshev wrote: >> Yes, doing this as a separate PR is fine with me. > > @jaikiran Let me clean up the comments that are not anymore accurate in this particular PR. I personally try to avoid this type of changes that only touch the whitespace or comments blocks, including the copyright header ones, because they increase the number of connections between unrelated changes, that makes the fix less portable. @sercher, it's OK if you leave the test in the current form. Just fixing the `@summary` test on the test definition should be enough. I have spoken to others and the agreement is that since we already have similar tests in this area, it probably is a better thing to let this test stay in this manner instead of devicing some new way to test this. Sorry about the previous guidance to update these test comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2580623450 From djelinski at openjdk.org Tue Dec 2 14:50:04 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 2 Dec 2025 14:50:04 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: <5Xi3KzSpKO5zUPBdESbgG7zc7JQmTjwjWgyVxiqN3Ic=.2464c8db-275e-43b7-9893-4c7cefac9f0e@github.com> References:

<5Xi3KzSpKO5zUPBdESbgG7zc7JQmTjwjWgyVxiqN3Ic=.2464c8db-275e-43b7-9893-4c7cefac9f0e@github.com> Message-ID: On Tue, 2 Dec 2025 14:01:20 GMT, Sergey Chernyshev wrote: >> @vy The test excercises the same code path as in the BCJSSE case, that throws an exception on non-LDH symbols. Segments of IPv4 literal adresses are all LDH, so they do not trigger any exception. Adding an IPAddressUtil.isIPv4LiteralAddress() check in the above condition is purely to mirror SSLSocketImpl behavior, as I thought initially. >> >> On the other hand, should we then add a negative test with a certificate that doesn't have a SAN extension (or the 127.0.0.1 ipv4 address in it), that should fail in the HostnameVerifier when the 'https://127.0.0.1' is requested? > > @djelinski would you think such a negative test is needed here? > On the other hand, should we then add a negative test with a certificate that doesn't have a SAN extension (or the 127.0.0.1 ipv4 address in it), that should fail in the HostnameVerifier when the 'https://127.0.0.1/' is requested? No, such test would fail whether we use setServerNames or not. I think @vy is asking for a check that the SSLParameters passed to SSLSocket#setSSLParameters have no serverNames configured. That should be reasonably easy to do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581507151 From myankelevich at openjdk.org Tue Dec 2 15:05:29 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 2 Dec 2025 15:05:29 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 14:29:34 GMT, Sergey Chernyshev wrote: >> Hi all, >> >> Let me propose a fix and a test case for JDK-8369950. >> >> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. >> >> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). >> >> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. >> >> SNIHostName, as defined in >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 >> >> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. >> >> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see >> >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 >> >> Testing: >> - standard jtreg tests goups showed no regressions >> - the new test passes with the fix and fails otherwise >> - passes also with BCJSSE in FIPS and standard mode >> >>

BCJSSE standard

Message-ID: On Tue, 2 Dec 2025 15:02:23 GMT, Mikhail Yankelevich wrote: >> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: >> >> - addressed more review comments >> - addressed review comments > > test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 65: > >> 63: * Turn on SSL debugging? >> 64: */ >> 65: static boolean debug = Boolean.getBoolean("test.debug"); > > Actually, do we even need this? Wouldn't it be easier to set `javax.net.debug` in the `@run` call? It's `othervm` already. > Sorry for confusion, didn't think about it at first @myankelev should I revert the suggested change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581641252 From myankelevich at openjdk.org Tue Dec 2 15:25:09 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 2 Dec 2025 15:25:09 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 15:17:21 GMT, Sergey Chernyshev wrote: >> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 65: >> >>> 63: * Turn on SSL debugging? >>> 64: */ >>> 65: static boolean debug = Boolean.getBoolean("test.debug"); >> >> Actually, do we even need this? Wouldn't it be easier to set `javax.net.debug` in the `@run` call? It's `othervm` already. >> Sorry for confusion, didn't think about it at first > > @myankelev should I revert the suggested change? Nope, it's fine as it is now, but if you want you can remove this debug flag completely. It's up to you ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581661759 From dfuchs at openjdk.org Tue Dec 2 15:30:47 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 2 Dec 2025 15:30:47 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

BCJSSE standard

Message-ID: On Tue, 2 Dec 2025 15:36:29 GMT, Mikhail Yankelevich wrote: >> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: >> >> - addressed more review comments >> - addressed review comments > > test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 76: > >> 74: SSLServerSocketFactory sslssf = >> 75: new SimpleSSLContext().get().getServerSocketFactory(); >> 76: SSLServerSocket sslServerSocket = > > Nit: could you please keep the lines under 80 characters long. There are a few instances in this file ok. > test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 153: > >> 151: SubjectAltNameIPv6() throws Exception { >> 152: startServer(); >> 153: startClient(); > > Do you think it might be better to call doClientSide here directly? ok, accepted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581969554 PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2581975687 From schernyshev at openjdk.org Tue Dec 2 16:50:23 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 2 Dec 2025 16:50:23 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 15:40:19 GMT, Mikhail Yankelevich wrote: >> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: >> >> - addressed more review comments >> - addressed review comments > > test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 60: > >> 58: * Is the server ready to serve? >> 59: */ >> 60: volatile static boolean serverReady = false; > > I think this might be better to make this a `CountDownLatch` ok, accepted. > test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 110: > >> 108: >> 109: SSLSocketFactory sf = new SimpleSSLContext().get().getSocketFactory(); >> 110: URL url = new URL("https://[::1]:" + serverPort + "/index.html"); > > Suggestion: > > URL url = > new URI("https://[::1]:" + serverPort + "/index.html").toURL(); I think the block is better readable without it. > test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 165: > >> 163: >> 164: void startServer() throws Exception { >> 165: serverThread = new Thread() { > > Suggestion: > > serverThread = new Thread(() -> { > > What do you think? This makes sense. I will set the /contributer manually later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582027880 PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582024160 PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582019908 From schernyshev at openjdk.org Tue Dec 2 16:50:25 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 2 Dec 2025 16:50:25 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 15:22:27 GMT, Mikhail Yankelevich wrote: >> @myankelev should I revert the suggested change? > > Nope, it's fine as it is now, but if you want you can remove this debug flag completely. It's up to you Thanks @myankelev , i will update the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582026811 From myankelevich at openjdk.org Tue Dec 2 16:54:45 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 2 Dec 2025 16:54:45 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 16:46:29 GMT, Sergey Chernyshev wrote: >> test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 110: >> >>> 108: >>> 109: SSLSocketFactory sf = new SimpleSSLContext().get().getSocketFactory(); >>> 110: URL url = new URL("https://[::1]:" + serverPort + "/index.html"); >> >> Suggestion: >> >> URL url = >> new URI("https://[::1]:" + serverPort + "/index.html").toURL(); > > I think the block is better readable without it. It's deprecated since version 20 I think ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582045071 From dfuchs at openjdk.org Tue Dec 2 17:01:09 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 2 Dec 2025 17:01:09 GMT Subject: RFR: 8372951: The property jdk.httpclient.quic.maxBidiStreams should be renamed to jdk.internal Message-ID: <_11WiMsb0ZfpYvClQjH87a6YE2kDYNlhpOVPOVT5ghs=.92a35317-712f-46f2-8f78-9f8e87ddb38d@github.com> The `jdk.httpclient.quic.maxBidiStreams` is an undocumented system property only used in tests. This property is only useful to control the default HTTP/3 test server implementation. It will never be documented or exposed. It should be clearly labelled as internal. The HTTP/3 client always provide a value of 0 for the `initial_max_streams_bidi` transport parameter, so the default value that the quic stack uses internally to set the parameter if no value is provided is never used on the client side. The `H3StreamLimitReachedTest` can be used to verify the change - it won't pass if the property is not correctly configured in the test. I have also taken this opportunity to add comments to the `H3StreamLimitReachedTest` and the `StreamLimitTest`, to explain the logic of each test. With this I believe that we can also say that this change will fix [JDK-8365794](https://bugs.openjdk.org/browse/JDK-8365794). ------------- Commit messages: - rename maxBidiStreams property - fix CLASS_NAME constant - 8365794 Changes: https://git.openjdk.org/jdk/pull/28611/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28611&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372951 Stats: 62 lines in 4 files changed: 52 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28611.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28611/head:pull/28611 PR: https://git.openjdk.org/jdk/pull/28611 From schernyshev at openjdk.org Tue Dec 2 17:14:15 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 2 Dec 2025 17:14:15 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v3] In-Reply-To: References: Message-ID: > Hi all, > > Let me propose a fix and a test case for JDK-8369950. > > The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. > > In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). > > The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. > > SNIHostName, as defined in > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 > > has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. > > The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see > > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 > > Testing: > - standard jtreg tests goups showed no regressions > - the new test passes with the fix and fails otherwise > - passes also with BCJSSE in FIPS and standard mode > >

BCJSSE standard

Message-ID: On Tue, 2 Dec 2025 16:51:45 GMT, Mikhail Yankelevich wrote: >> I think the block is better readable without it. > > It's deprecated since version 20 I think Ahh, ok, i read it wrong, apologies. URI is the modern one, exactly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2582120479 From schernyshev at openjdk.org Tue Dec 2 17:28:02 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 2 Dec 2025 17:28:02 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v4] In-Reply-To: References: Message-ID: > Hi all, > > Let me propose a fix and a test case for JDK-8369950. > > The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. > > In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). > > The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. > > SNIHostName, as defined in > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 > > has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. > > The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see > > https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 > > Testing: > - standard jtreg tests goups showed no regressions > - the new test passes with the fix and fails otherwise > - passes also with BCJSSE in FIPS and standard mode > >

BCJSSE standard

Message-ID: <5CMXCgWmWnuATMxROM1zVobe9dv-6FrwCN7hJHfC8dc=.e153adc5-f91f-4fba-9ffe-eced1ab9cac6@github.com> On Mon, 1 Dec 2025 19:03:50 GMT, Stuart Monteith wrote: > That was my mistake - I expected that with the foreign ABI being merged, discussions on internals would have reverted to here. In general they are -- but I find that one issue with PRs is that they tend to be very code-centric, whereas in some cases it might be useful to discuss design options more abstractly and _then_ converge towards an implementation. And doing design discussions via PR is suboptimal. But, you did right in bringing this up! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3603277207 From myankelevich at openjdk.org Tue Dec 2 23:30:12 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 2 Dec 2025 23:30:12 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v4] In-Reply-To: References:

Message-ID: On Tue, 2 Dec 2025 17:28:02 GMT, Sergey Chernyshev wrote: >> Hi all, >> >> Let me propose a fix and a test case for JDK-8369950. >> >> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. >> >> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). >> >> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. >> >> SNIHostName, as defined in >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 >> >> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. >> >> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see >> >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 >> >> Testing: >> - standard jtreg tests goups showed no regressions >> - the new test passes with the fix and fails otherwise >> - passes also with BCJSSE in FIPS and standard mode >> >>

BCJSSE standard

Message-ID: On Tue, 2 Dec 2025 23:26:41 GMT, Mikhail Yankelevich wrote: >> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: >> >> addressed few more review comments > > Thanks for considering me as a contributor to this ticket! I really appreciate it. > I personally feel that my suggestions weren't extensive enough to require adding me as a contributor, so there is need for it unless you think it's appropriate. > > Overall the ticket looks good, thank you for your updates! @myankelev Thank you for in-depth review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28577#issuecomment-3604526590 From schernyshev at openjdk.org Wed Dec 3 00:42:28 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 3 Dec 2025 00:42:28 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v5] In-Reply-To: References:

<5Xi3KzSpKO5zUPBdESbgG7zc7JQmTjwjWgyVxiqN3Ic=.2464c8db-275e-43b7-9893-4c7cefac9f0e@github.com> Message-ID: <0Mx2dW6pF5TeWOK9yE8NdzrU3tQaPrYbwGSIzrgLSE4=.94aee8c0-8aaa-4c30-b155-8b02431212e8@github.com> On Tue, 2 Dec 2025 14:47:00 GMT, Daniel Jeli?ski wrote: >> @djelinski would you think such a negative test is needed here? > >> On the other hand, should we then add a negative test with a certificate that doesn't have a SAN extension (or the 127.0.0.1 ipv4 address in it), that should fail in the HostnameVerifier when the 'https://127.0.0.1/' is requested? > > No, such test would fail whether we use setServerNames or not. > > I think @vy is asking for a check that the SSLParameters passed to SSLSocket#setSSLParameters have no serverNames configured. That should be reasonably easy to do. @djelinski @vy We could check the SSL parameters of the internal SSLSocket if the wrapper socket factory passed the inner SSLSocket to the caller. Please take a look at the updated test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2583227229 From djelinski at openjdk.org Wed Dec 3 07:37:05 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 3 Dec 2025 07:37:05 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v5] In-Reply-To: References:

Message-ID: On Wed, 3 Dec 2025 00:42:25 GMT, Sergey Chernyshev wrote: >> Hi all, >> >> Let me propose a fix and a test case for JDK-8369950. >> >> The failure reproduces with BCJSSE provider and all implementations of SSLSocket other than SSLSocketImpl. >> >> In the test case an anonymous wrapper is used, over the standard SSLSocketImpl, to simulate an external JSSE provider. The test case shows the same behavior as in BCJSSE (failure due to non-LDH ASCII characters in the SNI host name). >> >> The fix avoids constructing SNIHostName when the URL host name is an IPv4 or IPv6 literal address. Other than that, all other FQDN host names that have invalid characters (non-LDH ASCII characters) still produce that exception. >> >> SNIHostName, as defined in >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/javax/net/ssl/SNIHostName.java#L44-L66 >> >> has the fully qualified DNS hostname of the server. As follows from the section 3, "Server Name Indication", RFC 6066, `Literal IPv4 and IPv6 addresses are not permitted in "HostName"`. >> >> The fix mirrors the behavior of SSLSocketImpl, that avoids constructing the SNIHostName from literal addresses. Please see >> >> https://github.com/openjdk/jdk/blob/873f8a696fa45c7d94a164be20cf3c797ce7f2a6/src/java.base/share/classes/sun/security/ssl/Utilities.java#L110-L116 >> >> Testing: >> - standard jtreg tests goups showed no regressions >> - the new test passes with the fix and fails otherwise >> - passes also with BCJSSE in FIPS and standard mode >> >>

BCJSSE standard

>> >> >> STDOUT: >> STDERR: >> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty >> INFORMATION: Found boolean security property [keystore.type.compat]: true >> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty >> INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, TLS_RSA_*, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature >> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create >> WARNUNG: Ignoring unsupported entry in 'jdk.tls.disabledAlgorithms': rsa_pkcs1_sha1 usage HandshakeSignature >> Dez. 01, 2025 2:44:02 PM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create >> WARNUNG: Ignoring unsupported entry in 'jdk.tl... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > test that ipv4 literals do not propagate to the server names list test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 31: > 29: * @library /test/lib > 30: * @comment Insert -Djavax.net.debug=all into the following lines to enable SSL debugging > 31: * @run main/othervm SubjectAltNameIPv6 127.0.0.1 Since we also test against IPv4, I'd remove the mention of IPv6 from the class name (e.g., `SubjectAltNameIP`) and `@summary`. test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 136: > 134: */ > 135: conn.setSSLSocketFactory(wrapSocketFactory(sf, > 136: sslSocket -> clientSSLSocket = sslSocket)); Shall we first assert that `clientSSLSocket == null` before assignment? test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 140: > 138: > 139: var sniSN = clientSSLSocket.getSSLParameters().getServerNames(); > 140: if( sniSN != null && !sniSN.isEmpty()) { `if( sniSN` ? `if (sniSN` test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIPv6.java line 152: > 150: public static void main(String[] args) throws Exception { > 151: > 152: if (!IPSupport.hasIPv6()) { Suggestion: if (IPAddressUtil.isIPv6LiteralAddress(args[0]) && !IPSupport.hasIPv6()) { Note that you need to import `sun.net.util.IPAddressUtil` first. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2584149111 PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2584153074 PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2584160215 PR Review Comment: https://git.openjdk.org/jdk/pull/28577#discussion_r2584176475 From djelinski at openjdk.org Wed Dec 3 10:47:40 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 3 Dec 2025 10:47:40 GMT Subject: RFR: 8372958: SocketInputStream.read throws SocketException instead of returning -1 when input shutdown In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 07:47:40 GMT, Alan Bateman wrote: > Invoking Socket.shutdownInput at around the same time that another thread is attempts to read or is blocked in read on the same Socket has always been problematic on Windows. For virtual threads, the read may fail with a SocketException exception like "A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call". The change proposed here to change the SocketImpl to handle the async shutdownInput and cause read to return -1. > > Tests for async shutdownInput and shutdownOutput are added to BlockingSocketsOps. Some minor drive by clean-up to use a value source for the tests that exercise both untimed and timed cases. Similar cleanup in BlockingChannelOps as it tests the socket adapters doing both untimed and timed reads. The existing test for async shutdown with platform threads is migrated to JUnit as part of the change. > > Testing: tier1 + tier2, test repeat runs of the modified tests to ensure they are stable. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28626#pullrequestreview-3534415275 From michaelm at openjdk.org Wed Dec 3 11:17:38 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 3 Dec 2025 11:17:38 GMT Subject: RFR: 8372958: SocketInputStream.read throws SocketException instead of returning -1 when input shutdown In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 07:47:40 GMT, Alan Bateman wrote: > Invoking Socket.shutdownInput at around the same time that another thread is attempts to read or is blocked in read on the same Socket has always been problematic on Windows. For virtual threads, the read may fail with a SocketException exception like "A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call". The change proposed here to change the SocketImpl to handle the async shutdownInput and cause read to return -1. > > Tests for async shutdownInput and shutdownOutput are added to BlockingSocketsOps. Some minor drive by clean-up to use a value source for the tests that exercise both untimed and timed cases. Similar cleanup in BlockingChannelOps as it tests the socket adapters doing both untimed and timed reads. The existing test for async shutdown with platform threads is migrated to JUnit as part of the change. > > Testing: tier1 + tier2, test repeat runs of the modified tests to ensure they are stable. Looks fine ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28626#pullrequestreview-3534557280 From duke at openjdk.org Wed Dec 3 12:16:44 2025 From: duke at openjdk.org (EunHyunsu) Date: Wed, 3 Dec 2025 12:16:44 GMT Subject: RFR: 8371903: HttpClient: improve handling of HTTP/2 GOAWAY frames with error code Message-ID: ### Problem When the HTTP/2 client receives a GOAWAY frame with a non-zero error code, the current implementation discards both the error code and debug data. Users only see generic "Connection closed by peer" errors without any information about why the server terminated the connection. ### Solution Per [RFC 9113 ?5.4.1](https://www.rfc-editor.org/rfc/rfc9113.html#section-5.4.1), a GOAWAY frame with a non-zero error code indicates a connection error requiring immediate closure. This fix: 1. **Distinguishes** graceful shutdown (NO_ERROR) from connection errors 2. **Preserves** error code and debug data in exception messages 3. **Categorizes** streams based on `lastStreamId`: - Streams with ID > `lastStreamId`: Marked as unprocessed for automatic retry - Streams with ID ? `lastStreamId`: Failed with detailed error information ### Changes **Core Implementation** (`Http2Connection.java`): - Modified `handleGoAway()` to check error code and route appropriately - Added `handleGoAwayWithError()` method that: - Extracts error code and debug data from GOAWAY frame - Creates meaningful error messages with error name, hex code, and debug data - Properly categorizes streams for retry or failure **Test Infrastructure**: - `Http2TestServerConnection.sendGoAway(int, int, byte[])`: Supports custom error codes - `Http2TestExchangeImpl.getServerConnection()`: Accessor for test handlers - `GoAwayWithErrorTest`: Verifies proper error propagation ### Example **Before:** IOException: Connection closed by peer **After:** IOException: Received GOAWAY with error code Protocol error (0x1): Invalid HEADERS frame ### Testing - New `GoAwayWithErrorTest` passes - Existing HTTP/2 tests unaffected (NO_ERROR path unchanged) - Backward compatible (no public API changes) ------------- Commit messages: - 8371903: Preserve error code and debug data from HTTP/2 GOAWAY frames Changes: https://git.openjdk.org/jdk/pull/28632/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28632&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371903 Stats: 292 lines in 4 files changed: 290 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28632.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28632/head:pull/28632 PR: https://git.openjdk.org/jdk/pull/28632 From jpai at openjdk.org Wed Dec 3 12:44:30 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 12:44:30 GMT Subject: RFR: 8372951: The property jdk.httpclient.quic.maxBidiStreams should be renamed to jdk.internal In-Reply-To: <_11WiMsb0ZfpYvClQjH87a6YE2kDYNlhpOVPOVT5ghs=.92a35317-712f-46f2-8f78-9f8e87ddb38d@github.com> References: <_11WiMsb0ZfpYvClQjH87a6YE2kDYNlhpOVPOVT5ghs=.92a35317-712f-46f2-8f78-9f8e87ddb38d@github.com> Message-ID: On Tue, 2 Dec 2025 16:53:23 GMT, Daniel Fuchs wrote: > The `jdk.httpclient.quic.maxBidiStreams` is an undocumented system property only used in tests. This property is only useful to control the default HTTP/3 test server implementation. It will never be documented or exposed. It should be clearly labelled as internal. > The HTTP/3 client always provide a value of 0 for the `initial_max_streams_bidi` transport parameter, so the default value that the quic stack uses internally to set the parameter if no value is provided is never used on the client side. > > The `H3StreamLimitReachedTest` can be used to verify the change - it won't pass if the property is not correctly configured in the test. > > I have also taken this opportunity to add comments to the `H3StreamLimitReachedTest` and the `StreamLimitTest`, to explain the logic of each test. > > With this I believe that we can also say that this change will fix [JDK-8365794](https://bugs.openjdk.org/browse/JDK-8365794). src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java line 179: > 177: // The default value for the max_idle_timeout transport parameter that a QuicConnectionImpl > 178: // will send to its peer, if no value is provided by the higher level protocol. > 179: public static final int DEFAULT_MAX_INITIAL_TIMEOUT = Math.clamp( Hello Daniel, I think this comment is an oversight. This `DEFAULT_MAX_INITIAL_TIMEOUT` and the corresponding property control the maximum amount of time we wait for the connection attempt, against a server, to respond with an `INITIAL` packet. It doesn't control the idle timeout transport parameter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28611#discussion_r2584956772 From jpai at openjdk.org Wed Dec 3 12:52:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 12:52:07 GMT Subject: RFR: 8372951: The property jdk.httpclient.quic.maxBidiStreams should be renamed to jdk.internal In-Reply-To: <_11WiMsb0ZfpYvClQjH87a6YE2kDYNlhpOVPOVT5ghs=.92a35317-712f-46f2-8f78-9f8e87ddb38d@github.com> References: <_11WiMsb0ZfpYvClQjH87a6YE2kDYNlhpOVPOVT5ghs=.92a35317-712f-46f2-8f78-9f8e87ddb38d@github.com> Message-ID: On Tue, 2 Dec 2025 16:53:23 GMT, Daniel Fuchs wrote: > The `jdk.httpclient.quic.maxBidiStreams` is an undocumented system property only used in tests. This property is only useful to control the default HTTP/3 test server implementation. It will never be documented or exposed. It should be clearly labelled as internal. > The HTTP/3 client always provide a value of 0 for the `initial_max_streams_bidi` transport parameter, so the default value that the quic stack uses internally to set the parameter if no value is provided is never used on the client side. > > The `H3StreamLimitReachedTest` can be used to verify the change - it won't pass if the property is not correctly configured in the test. > > I have also taken this opportunity to add comments to the `H3StreamLimitReachedTest` and the `StreamLimitTest`, to explain the logic of each test. > > With this I believe that we can also say that this change will fix [JDK-8365794](https://bugs.openjdk.org/browse/JDK-8365794). test/jdk/java/net/httpclient/http3/H3StreamLimitReachedTest.java line 43: > 41: * for the retry. > 42: * @bug 8372951 > 43: * @comment this test also tests bug 8372951 Nit - i think we can remove these `@comment` lines because the `@bug` already states that this tests `8372951`. If we do retain this comment line, then it would mean we have to keep updating it (along with `@bug` every time there a new bug fix this test verifies). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28611#discussion_r2584987591 From alanb at openjdk.org Wed Dec 3 13:07:13 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Dec 2025 13:07:13 GMT Subject: RFR: 8372958: SocketInputStream.read throws SocketException instead of returning -1 when input shutdown In-Reply-To: References: Message-ID: <4u1usvCrVhEfW4p182tW_JOvUixWgdgn2ydN4AMbdt0=.22bbf4d8-74ca-41fd-ae47-ff3781bbad3d@github.com> On Wed, 3 Dec 2025 07:47:40 GMT, Alan Bateman wrote: > Invoking Socket.shutdownInput at around the same time that another thread attempts to read or is blocked in read on the same Socket has always been problematic on Windows. For virtual threads, the read may fail with a SocketException exception like "A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call". The change proposed here to change the SocketImpl to handle the async shutdownInput and cause read to return -1. > > Tests for async shutdownInput and shutdownOutput are added to BlockingSocketsOps. Some minor drive by clean-up to use a value source for the tests that exercise both untimed and timed cases. Similar cleanup in BlockingChannelOps as it tests the socket adapters doing both untimed and timed reads. The existing test for async shutdown with platform threads is migrated to JUnit as part of the change. > > Testing: tier1 + tier2, test repeat runs of the modified tests to ensure they are stable. Thanks for quick review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28626#issuecomment-3606752964 From alanb at openjdk.org Wed Dec 3 13:07:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Dec 2025 13:07:14 GMT Subject: Integrated: 8372958: SocketInputStream.read throws SocketException instead of returning -1 when input shutdown In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 07:47:40 GMT, Alan Bateman wrote: > Invoking Socket.shutdownInput at around the same time that another thread attempts to read or is blocked in read on the same Socket has always been problematic on Windows. For virtual threads, the read may fail with a SocketException exception like "A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call". The change proposed here to change the SocketImpl to handle the async shutdownInput and cause read to return -1. > > Tests for async shutdownInput and shutdownOutput are added to BlockingSocketsOps. Some minor drive by clean-up to use a value source for the tests that exercise both untimed and timed cases. Similar cleanup in BlockingChannelOps as it tests the socket adapters doing both untimed and timed reads. The existing test for async shutdown with platform threads is migrated to JUnit as part of the change. > > Testing: tier1 + tier2, test repeat runs of the modified tests to ensure they are stable. This pull request has now been integrated. Changeset: afb6a0c2 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/afb6a0c2fecdb2114715290d5d463c9dccf93c28 Stats: 328 lines in 4 files changed: 98 ins; 160 del; 70 mod 8372958: SocketInputStream.read throws SocketException instead of returning -1 when input shutdown Reviewed-by: djelinski, michaelm ------------- PR: https://git.openjdk.org/jdk/pull/28626 From dfuchs at openjdk.org Wed Dec 3 14:10:15 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 3 Dec 2025 14:10:15 GMT Subject: RFR: 8372951: The property jdk.httpclient.quic.maxBidiStreams should be renamed to jdk.internal In-Reply-To: References: <_11WiMsb0ZfpYvClQjH87a6YE2kDYNlhpOVPOVT5ghs=.92a35317-712f-46f2-8f78-9f8e87ddb38d@github.com> Message-ID: On Wed, 3 Dec 2025 12:49:31 GMT, Jaikiran Pai wrote: >> The `jdk.httpclient.quic.maxBidiStreams` is an undocumented system property only used in tests. This property is only useful to control the default HTTP/3 test server implementation. It will never be documented or exposed. It should be clearly labelled as internal. >> The HTTP/3 client always provide a value of 0 for the `initial_max_streams_bidi` transport parameter, so the default value that the quic stack uses internally to set the parameter if no value is provided is never used on the client side. >> >> The `H3StreamLimitReachedTest` can be used to verify the change - it won't pass if the property is not correctly configured in the test. >> >> I have also taken this opportunity to add comments to the `H3StreamLimitReachedTest` and the `StreamLimitTest`, to explain the logic of each test. >> >> With this I believe that we can also say that this change will fix [JDK-8365794](https://bugs.openjdk.org/browse/JDK-8365794). > > test/jdk/java/net/httpclient/http3/H3StreamLimitReachedTest.java line 43: > >> 41: * for the retry. >> 42: * @bug 8372951 >> 43: * @comment this test also tests bug 8372951 > > Nit - i think we can remove these `@comment` lines because the `@bug` already states that this tests `8372951`. If we do retain this comment line, then it would mean we have to keep updating it (along with `@bug` every time there a new bug fix this test verifies). There was no `@bug` comment before, so I didn't want to give the impression that this test only tested `@bug 8372951`. This is just an indication that it can also be used to test this particular fix ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28611#discussion_r2585267179 From dfuchs at openjdk.org Wed Dec 3 14:14:10 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 3 Dec 2025 14:14:10 GMT Subject: RFR: 8372951: The property jdk.httpclient.quic.maxBidiStreams should be renamed to jdk.internal [v2] In-Reply-To: <_11WiMsb0ZfpYvClQjH87a6YE2kDYNlhpOVPOVT5ghs=.92a35317-712f-46f2-8f78-9f8e87ddb38d@github.com> References: <_11WiMsb0ZfpYvClQjH87a6YE2kDYNlhpOVPOVT5ghs=.92a35317-712f-46f2-8f78-9f8e87ddb38d@github.com> Message-ID: <8ycLk_uNIvpq6xs2LVxkNR68cIur5zY4zolZgXMHZbg=.86e20334-296a-4663-ab67-b8b246dec3c5@github.com> > The `jdk.httpclient.quic.maxBidiStreams` is an undocumented system property only used in tests. This property is only useful to control the default HTTP/3 test server implementation. It will never be documented or exposed. It should be clearly labelled as internal. > The HTTP/3 client always provide a value of 0 for the `initial_max_streams_bidi` transport parameter, so the default value that the quic stack uses internally to set the parameter if no value is provided is never used on the client side. > > The `H3StreamLimitReachedTest` can be used to verify the change - it won't pass if the property is not correctly configured in the test. > > I have also taken this opportunity to add comments to the `H3StreamLimitReachedTest` and the `StreamLimitTest`, to explain the logic of each test. > > With this I believe that we can also say that this change will fix [JDK-8365794](https://bugs.openjdk.org/browse/JDK-8365794). Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - review feedback update wrong comment - Merge branch 'master' into StreamLimitTest-8372951 - rename maxBidiStreams property - fix CLASS_NAME constant - 8365794 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28611/files - new: https://git.openjdk.org/jdk/pull/28611/files/a8d416c7..c0448d88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28611&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28611&range=00-01 Stats: 1953 lines in 55 files changed: 1284 ins; 251 del; 418 mod Patch: https://git.openjdk.org/jdk/pull/28611.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28611/head:pull/28611 PR: https://git.openjdk.org/jdk/pull/28611 From jpai at openjdk.org Wed Dec 3 15:07:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 15:07:57 GMT Subject: RFR: 8372951: The property jdk.httpclient.quic.maxBidiStreams should be renamed to jdk.internal [v2] In-Reply-To: <8ycLk_uNIvpq6xs2LVxkNR68cIur5zY4zolZgXMHZbg=.86e20334-296a-4663-ab67-b8b246dec3c5@github.com> References: <_11WiMsb0ZfpYvClQjH87a6YE2kDYNlhpOVPOVT5ghs=.92a35317-712f-46f2-8f78-9f8e87ddb38d@github.com> <8ycLk_uNIvpq6xs2LVxkNR68cIur5zY4zolZgXMHZbg=.86e20334-296a-4663-ab67-b8b246dec3c5@github.com> Message-ID: On Wed, 3 Dec 2025 14:14:10 GMT, Daniel Fuchs wrote: >> The `jdk.httpclient.quic.maxBidiStreams` is an undocumented system property only used in tests. This property is only useful to control the default HTTP/3 test server implementation. It will never be documented or exposed. It should be clearly labelled as internal. >> The HTTP/3 client always provide a value of 0 for the `initial_max_streams_bidi` transport parameter, so the default value that the quic stack uses internally to set the parameter if no value is provided is never used on the client side. >> >> The `H3StreamLimitReachedTest` can be used to verify the change - it won't pass if the property is not correctly configured in the test. >> >> I have also taken this opportunity to add comments to the `H3StreamLimitReachedTest` and the `StreamLimitTest`, to explain the logic of each test. >> >> With this I believe that we can also say that this change will fix [JDK-8365794](https://bugs.openjdk.org/browse/JDK-8365794). > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - review feedback update wrong comment > - Merge branch 'master' into StreamLimitTest-8372951 > - rename maxBidiStreams property > - fix CLASS_NAME constant > - 8365794 Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28611#pullrequestreview-3535508394 From dfuchs at openjdk.org Wed Dec 3 15:36:56 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 3 Dec 2025 15:36:56 GMT Subject: Integrated: 8372951: The property jdk.httpclient.quic.maxBidiStreams should be renamed to jdk.internal In-Reply-To: <_11WiMsb0ZfpYvClQjH87a6YE2kDYNlhpOVPOVT5ghs=.92a35317-712f-46f2-8f78-9f8e87ddb38d@github.com> References: <_11WiMsb0ZfpYvClQjH87a6YE2kDYNlhpOVPOVT5ghs=.92a35317-712f-46f2-8f78-9f8e87ddb38d@github.com> Message-ID: On Tue, 2 Dec 2025 16:53:23 GMT, Daniel Fuchs wrote: > The `jdk.httpclient.quic.maxBidiStreams` is an undocumented system property only used in tests. This property is only useful to control the default HTTP/3 test server implementation. It will never be documented or exposed. It should be clearly labelled as internal. > The HTTP/3 client always provide a value of 0 for the `initial_max_streams_bidi` transport parameter, so the default value that the quic stack uses internally to set the parameter if no value is provided is never used on the client side. > > The `H3StreamLimitReachedTest` can be used to verify the change - it won't pass if the property is not correctly configured in the test. > > I have also taken this opportunity to add comments to the `H3StreamLimitReachedTest` and the `StreamLimitTest`, to explain the logic of each test. > > With this I believe that we can also say that this change will fix [JDK-8365794](https://bugs.openjdk.org/browse/JDK-8365794). This pull request has now been integrated. Changeset: af8977e4 Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/af8977e40661db2edec069d524f7c9352c7de850 Stats: 61 lines in 4 files changed: 51 ins; 0 del; 10 mod 8372951: The property jdk.httpclient.quic.maxBidiStreams should be renamed to jdk.internal 8365794: StreamLimitTest vs H3StreamLimitReachedTest: consider renaming or merging Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/28611 From schernyshev at openjdk.org Wed Dec 3 15:44:25 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 3 Dec 2025 15:44:25 GMT Subject: RFR: 8369950: TLS connection to IPv6 address fails with BCJSSE due to IllegalArgumentException [v5] In-Reply-To: