From eirbjo at gmail.com  Tue Apr  1 07:01:30 2025
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 1 Apr 2025 09:01:30 +0200
Subject: RFD: Use of ~ (tilde) when considering local and non-local file
 URLs
In-Reply-To: <CA+pBWhu9q9b34pgf9-JN0q+DaRAik=pwFgEkeGhGhwAzY=HWzA@mail.gmail.com>
References: <CA+pBWhu9q9b34pgf9-JN0q+DaRAik=pwFgEkeGhGhwAzY=HWzA@mail.gmail.com>
Message-ID: <CA+pBWhvQNFk5FB8v3zyP7d=5m4E4f_4=n6a-VFtv+uuj4p-8WA@mail.gmail.com>

On Wed, Mar 26, 2025 at 11:13?AM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

>
> In any case, I think if we could add the tilde logic
> to JarFileFactory::urlFor, then all these four checks would be equivalent
> and a prime candidate for a consolidating cleanup PR, perhaps also
> expanding a bit on the documentation for the consolidated method(s).
>

For reference, I filed a PR 24332 [1] which consolidates the 'local file
URL' checking in file: and jar: schemes, without changing this existing and
long-standing non-treatment of "~" as an alias for "localhost" in
JarFileFactory::urlFor.

Cheers,
Eirik.

[1] https://github.com/openjdk/jdk/pull/24332
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250401/46fb01e9/attachment-0001.htm>

From eirbjo at openjdk.org  Tue Apr  1 07:02:18 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Apr 2025 07:02:18 GMT
Subject: RFR: 8353278: Consolidate local file URL checks in jar: and file: URL
 schemes
Message-ID: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>

Please help review this cleanup PR which consolidates 'local file' URL checks across the 'file:' and 'jar:' URL scheme implementations and defines this check in terms of RFC 8089, Section 2.

This PR:

* Moves `URLJarFile.isFileURL` to `sun.net.www.ParseUtil` where it is documented according to RFC 8089 and given the more suitable name `isLocalFileURL`
* Updates `isLocalFileURL` to simplify an `if (x) return true;` statement to `return x;`
* Updates `URLJarFile.getJarFile` and `JarFileFactory.getOrCreate` to use `isLocalFileURL`
* Updates `JarFileFactory.urlFor` to use `isLocalFileURL` (while maintaining and documenting the historical and subtly different non-treatment of '~' as an alias for 'localhost')
* Updates `sun.net.www.protocol.file.Handler.openConnection` to use `isLocalFileURL` in windows/unix implementations

This is a pure cleanup / refactoring PR, no tests are updated here. Existing testing in this area seems sparse, so I have tried to limit the number of code tweaks to a minimium to make reviews easier.

Testing: GHA runs green, as well as tier2 on MacOS.

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

Commit messages:
 - Consolidate "local file" URL testing as defined by RFC 8089, Section 2

Changes: https://git.openjdk.org/jdk/pull/24332/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24332&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353278
  Stats: 46 lines in 5 files changed: 18 ins; 17 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24332/head:pull/24332

PR: https://git.openjdk.org/jdk/pull/24332

From eirbjo at gmail.com  Tue Apr  1 10:59:16 2025
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 1 Apr 2025 12:59:16 +0200
Subject: RFD: FTP fallback of the 'file:' URL scheme
In-Reply-To: <a6caeed7-abf7-4bb1-beb0-66e261795ac8@oracle.com>
References: <CA+pBWhvo-5pQWOVHNzAywbPSZO-A1JXZ2cwq5QFZBz7f+EYKAg@mail.gmail.com>
 <a6caeed7-abf7-4bb1-beb0-66e261795ac8@oracle.com>
Message-ID: <CA+pBWhtVtpL+oyUMjEg1Y4gYCR7pCRTO4nxBn=tVbRdkrr+E_g@mail.gmail.com>

On Mon, Mar 31, 2025 at 8:34?AM Alan Bateman <alan.bateman at oracle.com>
wrote:


> I recall digging into this a long time ago and concluded that it's was
> an interpretation of RFC 1738 section 3.10. I can't imagine anything
> relying on this in 2025 so disabling it, and introducing a system
> property to allow, seems reasonable.
>

Thanks for providing context, Alan. I agree it may make more sense to skip
the two-phase disablement of this feature. The number of people who rely on
this AND follow release notes in recent JDKs is probably very low.

I have filed https://bugs.openjdk.org/browse/JDK-8353440 to track disabling
this feature by default.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250401/17bad9bb/attachment.htm>

From dfuchs at openjdk.org  Tue Apr  1 13:27:25 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Apr 2025 13:27:25 GMT
Subject: RFR: 8353278: Consolidate local file URL checks in jar: and file:
 URL schemes
In-Reply-To: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
References: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
Message-ID: <3mJKCJZ2h-GDwJK11igoxZopLj_afeR2Jwx5C4bibhU=.c4644d8b-7f14-4934-abb9-3918dd97bd6d@github.com>

On Mon, 31 Mar 2025 14:46:32 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this cleanup PR which consolidates 'local file' URL checks across the 'file:' and 'jar:' URL scheme implementations and defines this check in terms of RFC 8089, Section 2.
> 
> This PR:
> 
> * Moves `URLJarFile.isFileURL` to `sun.net.www.ParseUtil` where it is documented according to RFC 8089 and given the more suitable name `isLocalFileURL`
> * Updates `isLocalFileURL` to simplify an `if (x) return true;` statement to `return x;`
> * Updates `URLJarFile.getJarFile` and `JarFileFactory.getOrCreate` to use `isLocalFileURL`
> * Updates `JarFileFactory.urlFor` to use `isLocalFileURL` (while maintaining and documenting the historical and subtly different non-treatment of '~' as an alias for 'localhost')
> * Updates `sun.net.www.protocol.file.Handler.openConnection` to use `isLocalFileURL` in windows/unix implementations
> 
> This is a pure cleanup / refactoring PR, no tests are updated here. Existing testing in this area seems sparse, so I have tried to limit the number of code tweaks to a minimium to make reviews easier.
> 
> Testing: GHA runs green, as well as tier2 on MacOS.

Hi Eirik,

This looks like a nice simplification. Thanks for proposing these changes. I would llike to run them in our CI but may not be able to get to that today.

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

PR Review: https://git.openjdk.org/jdk/pull/24332#pullrequestreview-2732684988

From duke at openjdk.org  Tue Apr  1 16:56:29 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 1 Apr 2025 16:56:29 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
Message-ID: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>

Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.

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

Commit messages:
 - Use HexFormat in URLDecoder

Changes: https://git.openjdk.org/jdk/pull/24314/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24314&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353453
  Stats: 6 lines in 1 file changed: 1 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24314/head:pull/24314

PR: https://git.openjdk.org/jdk/pull/24314

From myankelevich at openjdk.org  Tue Apr  1 16:56:29 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 1 Apr 2025 16:56:29 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
Message-ID: <VnzFy820r3cC3U0DNjH62GdwawsfNu1JoIHLE1mXA-Q=.a0fc6ba0-b1d3-453c-8e29-cec9afb575fe@github.com>

On Sat, 29 Mar 2025 17:27:20 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.

Hi! 
This commit must refer to an issue. Could you please create one and provide some background for the change here. 
Thank you

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

PR Comment: https://git.openjdk.org/jdk/pull/24314#issuecomment-2766466586

From liach at openjdk.org  Tue Apr  1 16:56:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 1 Apr 2025 16:56:29 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
Message-ID: <2WcGRv0A_hDlLh4wHutc7LbfjKsasU7wAfJMdRfEh7g=.cd80a5d0-c7ea-4364-9058-3ba0528f1a1e@github.com>

On Sat, 29 Mar 2025 17:27:20 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.

Is there a particular reason for this change? Like is this a significant performance bottleneck?

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

PR Comment: https://git.openjdk.org/jdk/pull/24314#issuecomment-2767724608

From duke at openjdk.org  Tue Apr  1 16:56:29 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 1 Apr 2025 16:56:29 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <2WcGRv0A_hDlLh4wHutc7LbfjKsasU7wAfJMdRfEh7g=.cd80a5d0-c7ea-4364-9058-3ba0528f1a1e@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
 <2WcGRv0A_hDlLh4wHutc7LbfjKsasU7wAfJMdRfEh7g=.cd80a5d0-c7ea-4364-9058-3ba0528f1a1e@github.com>
Message-ID: <VawBh5t63IQJIpQP8W5QzaJ5KAa5O7_iCLDhuHK44Ns=.f15ad859-cb49-4db9-bd5d-2b0e2b560d32@github.com>

On Tue, 1 Apr 2025 00:34:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> Is there a particular reason for this change? Like is this a significant performance bottleneck?

I don't know of a particular bottleneck specifically with `Integer.parseInt` in `URLDecoder`, however `URLDecoder#decode` is often there in the hot path for our applications in general; this change was more so motivated by the following:

- `HexFormat` is purpose built for this specific use case, whereas `Integer.parseInt` is generic (obviously).
- `HexFormat.fromHexDigits` uses a look up table and is in general far fewer lines of code.
- `HexFormat` is used throughout the JDK, so I surmised that the potential usage here might have just been missed.

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

PR Comment: https://git.openjdk.org/jdk/pull/24314#issuecomment-2767896209

From duke at openjdk.org  Tue Apr  1 16:58:23 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 1 Apr 2025 16:58:23 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <VnzFy820r3cC3U0DNjH62GdwawsfNu1JoIHLE1mXA-Q=.a0fc6ba0-b1d3-453c-8e29-cec9afb575fe@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
 <VnzFy820r3cC3U0DNjH62GdwawsfNu1JoIHLE1mXA-Q=.a0fc6ba0-b1d3-453c-8e29-cec9afb575fe@github.com>
Message-ID: <L9TKVyVghp5M-zbiLFhchZ_k0Q6qRiKPe1pigPanKOM=.52cf776e-ae18-4bbd-b0f9-90891089b14c@github.com>

On Mon, 31 Mar 2025 14:43:24 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Hi! This commit must refer to an issue. Could you please create one and provide some background for the change here. Thank you

I've updated the PR with the associated issue. I provided some background in my response to the other comment. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24314#issuecomment-2769991012

From dfuchs at openjdk.org  Tue Apr  1 17:27:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Apr 2025 17:27:16 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
Message-ID: <6iw-4ZtRyZk_pvlMk8rUnb1epsRZU5fw4kFGxpmyIY8=.fc212512-cc7e-4b51-b927-6573849e3682@github.com>

On Sat, 29 Mar 2025 17:27:20 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.

Interesting. Please run tier2 tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/24314#issuecomment-2770150459

From eirbjo at gmail.com  Tue Apr  1 19:09:45 2025
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 1 Apr 2025 21:09:45 +0200
Subject: RFD: Query param discrepancy in unix/windows file
 Handler:openConnection
Message-ID: <CA+pBWhtbvbYfZvX1X0pSd5rO50iHfk2g2+1AZSUQCnFNP=DJ+w@mail.gmail.com>

Hi,

*Observation:*

On Unix and Windows respectively, the following code runs fine:

Unix:
jshell> new URL("file://localhost/etc/hosts").openStream();
$8 ==> java.io.BufferedInputStream at 59f95c5d

Windows:
jshell> new
java.net.URL("file://localhost/C:/Windows/System32/drivers/etc/hosts").openStream()
$13 ==> java.io.BufferedInputStream at 33e5ccce

However, when we add a query parameter to the URL, the picture changes:

Unix:
jshell> new URL("file://localhost/etc/hosts?name=value").openStream();
$9 ==> java.io.BufferedInputStream at 4aa8f0b4

Windows:
jshell> new
java.net.URL("file://localhost/C:/Windows/System32/drivers/etc/hosts?name=value").openStream()
|  Exception java.io.FileNotFoundException:
C:\Windows\System32\drivers\etc\hosts?name=value (The filename, directory
name, or volume label syntax is incorrect)
|        at FileInputStream.open0 (Native Method)
|        at FileInputStream.open (FileInputStream.java:185)
|        at FileInputStream.<init> (FileInputStream.java:139)
|        at FileInputStream.<init> (FileInputStream.java:109)
|        at FileURLConnection.connect (FileURLConnection.java:83)
|        at FileURLConnection.getInputStream (FileURLConnection.java:185)
|        at URL.openStream (URL.java:1260)
|        at (#14:1)


*Analysis:*

Looking at the Windows implementation of sun.net.protocol.www.file.Handler,
it indeed uses URL::getFile when constructing the file path, while the unix
implementation uses URL::getPath.

Unlike the generic URI syntax described in RFC 3986, the file URI RFC 8082
does not include a query component in its syntax description.

This leaves the implementor the choice of ignoring query components (like
we do for Unix) or rejecting the URL (which we effectively, while not
explicitly, do for Windows).

*Action:*

I think it would make sense to align our implementations here. If we choose
to do so, I think it would make most sense to adjust the Windows
implementation to also ignore the query component by using URL::getPath
instead of URL::getFile, like we currently do for Unix.

Thoughts?

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250401/5e83c9bb/attachment.htm>

From vyazici at openjdk.org  Tue Apr  1 19:11:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 1 Apr 2025 19:11:05 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v4]
In-Reply-To: <gv5twQ0thv5xmzfYal-vhQ9_lJMZzj82aSvspWZHT-c=.fd03035c-5d59-4069-9bf5-19c28b8a47b9@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <tAIXaR9JwJp5BPPLXFmao8eS-gRZj_Wm7c9v369IZ5I=.515939fe-d758-4188-838e-554817c12a10@github.com>
 <40t49BmeSuVQO5l3QVn2CPMrVlZeokJz4I5tScdWYA8=.389bd5a5-df9f-44f1-95bd-a64d84835686@github.com>
 <gv5twQ0thv5xmzfYal-vhQ9_lJMZzj82aSvspWZHT-c=.fd03035c-5d59-4069-9bf5-19c28b8a47b9@github.com>
Message-ID: <dOgdhReO8g6YmXeggCrMhstKC4cESSuyuu8ga6_az90=.9b79f1cb-903e-4c7a-a918-d784a59e6eae@github.com>

On Thu, 27 Mar 2025 13:52:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java line 121:
>> 
>>> 119:      * {@link HttpResponse#connectionLabel() HttpResponse::connectionLabel}}
>>> 120:      */
>>> 121:     public String label() {
>> 
>> Perhaps make this method `final`?
>
> Maybe not. We could want to extend it to give an indication that the connection is TCP or TLS - or Quic in the future...

Made it `final` in 883135d8edc2f2a892152e42eda924d65686bc7a. Since the code is in an internal package, we can always relax it if needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2023531007

From rriggs at openjdk.org  Tue Apr  1 19:11:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 1 Apr 2025 19:11:17 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
Message-ID: <be06ubYaB-uiTnXF43CatCTU0iaHw6xsmZKMEgInkrQ=.5856eff9-8b65-4283-9d21-8ccbd13b3ee3@github.com>

On Sat, 29 Mar 2025 17:27:20 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.

src/java.base/share/classes/java/net/URLDecoder.java line 208:

> 206:                     while ( ((i+2) < numChars) &&
> 207:                             (c=='%')) {
> 208:                         int v = HexFormat.fromHexDigits(s, i + 1, i + 3);

Its worth noting that the exceptions thrown by HexFormat.fromHexDigits are different than those thrown by Integer.parseInt, as to the specific type and exception message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24314#discussion_r2023532637

From vyazici at openjdk.org  Tue Apr  1 19:11:02 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 1 Apr 2025 19:11:02 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v5]
In-Reply-To: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
Message-ID: <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>

> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
> 
> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Apply review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24154/files
  - new: https://git.openjdk.org/jdk/pull/24154/files/59a11ccc..883135d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=03-04

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24154/head:pull/24154

PR: https://git.openjdk.org/jdk/pull/24154

From vyazici at openjdk.org  Tue Apr  1 19:11:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 1 Apr 2025 19:11:04 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v4]
In-Reply-To: <JL_I4s2qV2FBXgU48la2-xEyM0aXG5_1kRBBokwvGPg=.c4b5c511-1689-4794-aca7-b3360ef022f3@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <tAIXaR9JwJp5BPPLXFmao8eS-gRZj_Wm7c9v369IZ5I=.515939fe-d758-4188-838e-554817c12a10@github.com>
 <JL_I4s2qV2FBXgU48la2-xEyM0aXG5_1kRBBokwvGPg=.c4b5c511-1689-4794-aca7-b3360ef022f3@github.com>
Message-ID: <hn8A4mqIWlCm6__bVeTcvyOFAaTDah_Ldwdw7E3WyRE=.20f5389a-1e8e-4057-b8d6-d67f0ff29af6@github.com>

On Thu, 27 Mar 2025 13:02:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve JavaDoc
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java line 103:
> 
>> 101:      * </p>
>> 102:      */
>> 103:     final String label;
> 
> I think this should be `private`.

Fixed in 883135d8edc2f2a892152e42eda924d65686bc7a.

> src/java.net.http/share/classes/jdk/internal/net/http/HttpResponseImpl.java line 44:
> 
>> 42:  * The implementation class for HttpResponse
>> 43:  */
>> 44: class HttpResponseImpl<T> implements HttpResponse<T>, RawChannel.Provider {
> 
> The copyright year on this file will need an update.

Fixed in 883135d8edc2f2a892152e42eda924d65686bc7a.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2023531901
PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2023531280

From vyazici at openjdk.org  Tue Apr  1 19:16:19 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 1 Apr 2025 19:16:19 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v4]
In-Reply-To: <nOQVYBkgi0EshKDd0slX5uYcv-1tK0OwQ-PI8ZvRO_A=.b4a1abe3-e892-4964-8146-0cedee3ec861@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <tAIXaR9JwJp5BPPLXFmao8eS-gRZj_Wm7c9v369IZ5I=.515939fe-d758-4188-838e-554817c12a10@github.com>
 <JL_I4s2qV2FBXgU48la2-xEyM0aXG5_1kRBBokwvGPg=.c4b5c511-1689-4794-aca7-b3360ef022f3@github.com>
 <KnRTrwmtR707Xgo50S7qF2rzRgQGIX_dvdzoVKn2dcA=.b43f1408-82a8-4fb4-a4a1-b64317c70aba@github.com>
 <XnpajXgUNOALWeMng5oyyPFtCjPRpQxrehDmG8WE9Es=.2fc8fe49-7b53-45b2-a6a4-aec1c0a51371@github.com>
 <nOQVYBkgi0EshKDd0slX5uYcv-1tK0OwQ-PI8ZvRO_A=.b4a1abe3-e892-4964-8146-0cedee3ec861@github.com>
Message-ID: <MPh890s_cpVmaes8gA0ks9dOWjdqr27tEia1lLRRU4I=.b40c379d-b1c9-4004-bbe3-ecf9a0887399@github.com>

On Thu, 27 Mar 2025 15:24:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> The only use of HttpConnection.id is for ordering - so that connections can be placed in a ConcurrentSkipListSet.
>> 
>> I wasn't aware of that. Now that you mentioned it, I looked up the code which uses the Set to store these connections. And from what I can see, the order is only used during the closing of a HttpClient, to close these opened connections in that specific order. Did I miss any other usages of the order?
>> 
>> In any case, now that you corrected me about the usage of the `id` order, I agree that having the comment on the `id` field is fine and only remove it from the paragraph here.
>
> When we close a connection, we take it out of the set. So it's not about ordering the connection but about quickly finding the connection in that set.

It was already a puzzler for me to figure out `id` cannot be used for `label`, and `label` cannot be used for `id` either. Both are due to the fact that `label` can be shared across instances, whereas `id` cannot. In short, I've found it very helpful to thoroughly document their these fields' properties and what they serve for. Unless you have a strong objection, I'd like to keep the current form of documentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2023538966

From vyazici at openjdk.org  Tue Apr  1 19:21:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 1 Apr 2025 19:21:20 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v4]
In-Reply-To: <qjgXuVsn4GgXWo7GHg0u2blkrfT_h6r0wsn1Pt7oQZc=.012b7da6-a1ed-4d86-81ee-fc58e698a42f@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <tAIXaR9JwJp5BPPLXFmao8eS-gRZj_Wm7c9v369IZ5I=.515939fe-d758-4188-838e-554817c12a10@github.com>
 <qjgXuVsn4GgXWo7GHg0u2blkrfT_h6r0wsn1Pt7oQZc=.012b7da6-a1ed-4d86-81ee-fc58e698a42f@github.com>
Message-ID: <aeDyI4A1iU1EiSlcJMtrgubaUvITBvju5gcUE9sAi7c=.b7810218-94df-4a8e-976b-9912832cd94a@github.com>

On Thu, 27 Mar 2025 13:07:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve JavaDoc
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java line 81:
> 
>> 79:             = Comparator.comparing(HttpConnection::id);
>> 80: 
>> 81:     private static final AtomicLong LABEL_COUNTER = new AtomicLong();
> 
> In the API documentation on `HttpResponse.connectionLabel()` we talk about the connection label being unique within a `HttpClient` scope. i.e. two different `HttpClient` instances could have the same connectionLabel for a connection. I think that's the right scoping.
> 
> So given that, having a `static` field on a `HttpConnection` which keeps track of a connection label, may not be the right place to keep track of that state. In this proposed form, no two connections in two different HttpClient instances will ever have the same connectionLabel. I think this counter should probably be present on the `HttpClientImpl` as an instance field.

@jaikiran, what you're suggesting makes sense. I'm still exploring the interplay between the connection label and HTTP/3 server pushes. I will return back to your suggestion soon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2023544640

From liach at openjdk.org  Tue Apr  1 23:02:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 1 Apr 2025 23:02:26 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <be06ubYaB-uiTnXF43CatCTU0iaHw6xsmZKMEgInkrQ=.5856eff9-8b65-4283-9d21-8ccbd13b3ee3@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
 <be06ubYaB-uiTnXF43CatCTU0iaHw6xsmZKMEgInkrQ=.5856eff9-8b65-4283-9d21-8ccbd13b3ee3@github.com>
Message-ID: <8ceX3GH_4y6Sscj3FThghTPymDVvzraLGQPd_xk-lp4=.7647fa31-8fe8-479c-8f10-9afa2ad37f62@github.com>

On Tue, 1 Apr 2025 19:08:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.
>
> src/java.base/share/classes/java/net/URLDecoder.java line 208:
> 
>> 206:                     while ( ((i+2) < numChars) &&
>> 207:                             (c=='%')) {
>> 208:                         int v = HexFormat.fromHexDigits(s, i + 1, i + 3);
> 
> Its worth noting that the exceptions thrown by HexFormat.fromHexDigits are different than those thrown by Integer.parseInt, as to the specific type and exception message.

They are both NumberFormatException that is immediately handled by an enclosing catch block. This change should only affect the exception message for inputs fragments like %-F.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24314#discussion_r2023780945

From dfuchs at openjdk.org  Wed Apr  2 10:08:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Apr 2025 10:08:13 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <8ceX3GH_4y6Sscj3FThghTPymDVvzraLGQPd_xk-lp4=.7647fa31-8fe8-479c-8f10-9afa2ad37f62@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
 <be06ubYaB-uiTnXF43CatCTU0iaHw6xsmZKMEgInkrQ=.5856eff9-8b65-4283-9d21-8ccbd13b3ee3@github.com>
 <8ceX3GH_4y6Sscj3FThghTPymDVvzraLGQPd_xk-lp4=.7647fa31-8fe8-479c-8f10-9afa2ad37f62@github.com>
Message-ID: <3rUvTcaueXMF405h6x1PGklsHrtFw1-w6bxGFYk-hFI=.70207421-1812-4379-b429-361e044f4c64@github.com>

On Tue, 1 Apr 2025 22:59:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URLDecoder.java line 208:
>> 
>>> 206:                     while ( ((i+2) < numChars) &&
>>> 207:                             (c=='%')) {
>>> 208:                         int v = HexFormat.fromHexDigits(s, i + 1, i + 3);
>> 
>> Its worth noting that the exceptions thrown by HexFormat.fromHexDigits are different than those thrown by Integer.parseInt, as to the specific type and exception message.
>
> They are both NumberFormatException that is immediately handled by an enclosing catch block. This change should only affect the exception message for inputs fragments like %-F.

Right. And `NumberFormatException` is a subclass of `IllegalArgumentException` so that would remain compatible even if it were not caught and replaced by plain IAE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24314#discussion_r2024512784

From daniel.fuchs at oracle.com  Wed Apr  2 10:12:25 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 2 Apr 2025 11:12:25 +0100
Subject: RFD: Query param discrepancy in unix/windows file
 Handler:openConnection
In-Reply-To: <CA+pBWhtbvbYfZvX1X0pSd5rO50iHfk2g2+1AZSUQCnFNP=DJ+w@mail.gmail.com>
References: <CA+pBWhtbvbYfZvX1X0pSd5rO50iHfk2g2+1AZSUQCnFNP=DJ+w@mail.gmail.com>
Message-ID: <77b7c137-02a0-411c-8033-83add8f2c992@oracle.com>

Hi Eirik,

This is an old API and I suspect the current behavior has
been here from the start. I would prefer not to change
it, unless we really have to.

best regards,

-- daniel

On 01/04/2025 20:09, Eirik Bj?rsn?s wrote:
> Hi,
> 
> *Observation:*
> 
> On Unix and Windows respectively, the following code runs fine:
> 
> Unix:
> jshell> new URL("file://localhost/etc/hosts").openStream();
> $8 ==> java.io.BufferedInputStream at 59f95c5d
> 
> Windows:
> jshell> new 
> java.net.URL("file://localhost/C:/Windows/System32/drivers/etc/hosts").openStream()
> $13 ==> java.io.BufferedInputStream at 33e5ccce
> 
> However, when we add a query parameter to the URL, the picture changes:
> 
> Unix:
> jshell> new URL("file://localhost/etc/hosts?name=value").openStream();
> $9 ==> java.io.BufferedInputStream at 4aa8f0b4
> 
> Windows:
> jshell> new 
> java.net.URL("file://localhost/C:/Windows/System32/drivers/etc/hosts?name=value").openStream()
> | ?Exception java.io.FileNotFoundException: 
> C:\Windows\System32\drivers\etc\hosts?name=value (The filename, 
> directory name, or volume label syntax is incorrect)
> | ? ? ? ?at FileInputStream.open0 (Native Method)
> | ? ? ? ?at FileInputStream.open (FileInputStream.java:185)
> | ? ? ? ?at FileInputStream.<init> (FileInputStream.java:139)
> | ? ? ? ?at FileInputStream.<init> (FileInputStream.java:109)
> | ? ? ? ?at FileURLConnection.connect (FileURLConnection.java:83)
> | ? ? ? ?at FileURLConnection.getInputStream (FileURLConnection.java:185)
> | ? ? ? ?at URL.openStream (URL.java:1260)
> | ? ? ? ?at (#14:1)
> 
> 
> *Analysis:*
> 
> Looking at the Windows implementation of 
> sun.net.protocol.www.file.Handler, it indeed uses URL::getFile when 
> constructing the file path, while the unix implementation uses URL::getPath.
> 
> Unlike the generic URI syntax described in RFC 3986, the file URI RFC 
> 8082 does not include a query component in its syntax description.
> 
> This leaves the implementor the choice of ignoring query components 
> (like we do for Unix) or rejecting the URL (which we effectively, while 
> not explicitly, do for Windows).
> 
> *Action:*
> 
> I think it would make sense to align our implementations here. If we 
> choose to do so, I think it would make most sense to adjust the Windows 
> implementation to also ignore the query component by using URL::getPath 
> instead of URL::getFile, like we currently do for Unix.
> 
> Thoughts?
> 
> Eirik.


From jpai at openjdk.org  Wed Apr  2 11:03:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Apr 2025 11:03:54 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v4]
In-Reply-To: <MPh890s_cpVmaes8gA0ks9dOWjdqr27tEia1lLRRU4I=.b40c379d-b1c9-4004-bbe3-ecf9a0887399@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <tAIXaR9JwJp5BPPLXFmao8eS-gRZj_Wm7c9v369IZ5I=.515939fe-d758-4188-838e-554817c12a10@github.com>
 <JL_I4s2qV2FBXgU48la2-xEyM0aXG5_1kRBBokwvGPg=.c4b5c511-1689-4794-aca7-b3360ef022f3@github.com>
 <KnRTrwmtR707Xgo50S7qF2rzRgQGIX_dvdzoVKn2dcA=.b43f1408-82a8-4fb4-a4a1-b64317c70aba@github.com>
 <XnpajXgUNOALWeMng5oyyPFtCjPRpQxrehDmG8WE9Es=.2fc8fe49-7b53-45b2-a6a4-aec1c0a51371@github.com>
 <nOQVYBkgi0EshKDd0slX5uYcv-1tK0OwQ-PI8ZvRO_A=.b4a1abe3-e892-4964-8146-0cedee3ec861@github.com>
 <MPh890s_cpVmaes8gA0ks9dOWjdqr27tEia1lLRRU4I=.b40c379d-b1c9-4004-bbe3-ecf9a0887399@github.com>
Message-ID: <GAgpUeiPWdjNHUL3MTOqI1uEVAwbCBU2lv-1lO6748A=.926ab91b-a454-4121-bcf8-fe1fe2561eaa@github.com>

On Tue, 1 Apr 2025 19:13:36 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> When we close a connection, we take it out of the set. So it's not about ordering the connection but about quickly finding the connection in that set.
>
> It was already a puzzler for me to figure out `id` cannot be used for `label`, and `label` cannot be used for `id` either. Both are due to the fact that `label` can be shared across instances, whereas `id` cannot. In short, I've found it very helpful to thoroughly document their these fields' properties and what they serve for. Unless you have a strong objection, I'd like to keep the current form of documentation.

Hello Volkan, I think having the mention of ordering on the `id` field is OK. I still find it confusing to have this sentence on the `label`:

>
> As a result, compared to {@link #id}, this label does not give a total order among instances.

To me, this feels odd because `label` being a `String` typically wouldn't have been considered to be playing a role in ordering. Plus, in isolation, it's not clear what ordering this talks about (Daniel did explain to me that the `id` field is used in ordering of open connections. I haven't yet looked deeper at that code to see where that happens).

In any case, this is an internal class so if we do decide to use the current proposed text, that's OK with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2024595837

From jpai at openjdk.org  Wed Apr  2 11:10:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Apr 2025 11:10:52 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v5]
In-Reply-To: <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
Message-ID: <85yHuJ0fSjBVwvPmVyacNvYTLRa-bsADIuaawD4Vj5k=.cdb5ec21-1954-40c3-a7cc-433c132ee746@github.com>

On Tue, 1 Apr 2025 19:11:02 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review suggestions

src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java line 114:

> 112: 
> 113:     private static String nextLabel() {
> 114:         return "" + LABEL_COUNTER.getAndIncrement();

The first label that this will generate will be `0`. It might be OK, but I think it would be better if we start it as `1`. So maybe consider using `LABEL_COUNTER.incrementAndGet()` instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2024605799

From dfuchs at openjdk.org  Wed Apr  2 11:15:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Apr 2025 11:15:00 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v5]
In-Reply-To: <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
Message-ID: <T2_pjr7dnQhf3rIQxtu18pBwW5xa6YR6QRso6VM4vV4=.a054f9a5-8794-476b-be52-c7dec6d608e7@github.com>

On Tue, 1 Apr 2025 19:11:02 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review suggestions

src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java line 100:

> 98:      * {@link PlainHttpConnection} it wraps will share the same label. As a
> 99:      * result, compared to {@link #id}, this label does not give a total order
> 100:      * among instances.

Suggestion:

    /**
     * A label to identify the connection.
     * <p>
     * This label helps with associating multiple components participating in a
     * connection. For instance, an {@link AsyncSSLConnection} and the
     * {@link PlainHttpConnection} it wraps will share the same label.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2024608425

From dfuchs at openjdk.org  Wed Apr  2 11:14:59 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Apr 2025 11:14:59 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v4]
In-Reply-To: <GAgpUeiPWdjNHUL3MTOqI1uEVAwbCBU2lv-1lO6748A=.926ab91b-a454-4121-bcf8-fe1fe2561eaa@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <tAIXaR9JwJp5BPPLXFmao8eS-gRZj_Wm7c9v369IZ5I=.515939fe-d758-4188-838e-554817c12a10@github.com>
 <JL_I4s2qV2FBXgU48la2-xEyM0aXG5_1kRBBokwvGPg=.c4b5c511-1689-4794-aca7-b3360ef022f3@github.com>
 <KnRTrwmtR707Xgo50S7qF2rzRgQGIX_dvdzoVKn2dcA=.b43f1408-82a8-4fb4-a4a1-b64317c70aba@github.com>
 <XnpajXgUNOALWeMng5oyyPFtCjPRpQxrehDmG8WE9Es=.2fc8fe49-7b53-45b2-a6a4-aec1c0a51371@github.com>
 <nOQVYBkgi0EshKDd0slX5uYcv-1tK0OwQ-PI8ZvRO_A=.b4a1abe3-e892-4964-8146-0cedee3ec861@github.com>
 <MPh890s_cpVmaes8gA0ks9dOWjdqr27tEia1lLRRU4I=.b40c379d-b1c9-4004-bbe3-ecf9a0887399@github.com>
 <GAgpUeiPWdjNHUL3MTOqI1uEVAwbCBU2lv-1lO6748A=.926ab91b-a454-4121-bcf8-fe1fe2561eaa@github.com>
Message-ID: <wC4xX-6dhx8lOAZu4okoyoNsULjWv_idxtthcaFA7jQ=.3f00f4a4-b562-45b6-aa8f-010ec8b3a2e6@github.com>

On Wed, 2 Apr 2025 11:01:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> It was already a puzzler for me to figure out `id` cannot be used for `label`, and `label` cannot be used for `id` either. Both are due to the fact that `label` can be shared across instances, whereas `id` cannot. In short, I've found it very helpful to thoroughly document their these fields' properties and what they serve for. Unless you have a strong objection, I'd like to keep the current form of documentation.
>
> Hello Volkan, I think having the mention of ordering on the `id` field is OK. I still find it confusing to have this sentence on the `label`:
> 
>>
>> As a result, compared to {@link #id}, this label does not give a total order among instances.
> 
> To me, this feels odd because `label` being a `String` typically wouldn't have been considered to be playing a role in ordering. Plus, in isolation, it's not clear what ordering this talks about (Daniel did explain to me that the `id` field is used in ordering of open connections. I haven't yet looked deeper at that code to see where that happens).
> 
> In any case, this is an internal class so if we do decide to use the current proposed text, that's OK with me.

I agree with Jaikiran: I would just remove the last sentence in this pargraph.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2024607986

From jpai at openjdk.org  Wed Apr  2 11:15:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Apr 2025 11:15:01 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v5]
In-Reply-To: <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
Message-ID: <yhByNisNeZXG1n6t_c2zvJW2sngfTVs7varhdn6vj-k=.325472bb-a411-4d28-9d26-30db51b279ad@github.com>

On Tue, 1 Apr 2025 19:11:02 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review suggestions

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 68:

> 66: import static org.junit.jupiter.api.Assertions.assertTrue;
> 67: 
> 68: @SuppressWarnings("OptionalGetWithoutIsPresent")

I haven't seen this `OptionalGetWithoutIsPresent` warning before and looking into the JDK repo I don't see it being used or recognized any place else. Is this meant for some specific IDEs?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2024611186

From jpai at openjdk.org  Wed Apr  2 11:27:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Apr 2025 11:27:52 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v5]
In-Reply-To: <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
Message-ID: <_aQVk4asCWzFDV_1H3-ZINSwT3NCWeZ0QoWQ7wGb838=.317526d9-369f-48f2-8186-93328c5bf8fe@github.com>

On Tue, 1 Apr 2025 19:11:02 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review suggestions

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 83:

> 81: 
> 82:     // Start with a fresh client having no connections in the pool
> 83:     @AutoClose

I hadn't come across this JUnit Jupiter annotation before. Reading through https://junit.org/junit5/docs/current/user-guide/#writing-tests-built-in-extensions-AutoClose it appears to be a convenience mechanism for managing closing of the resources at the "right time". That doc states:

> Specifically, if the test class is configured with @TestInstance(Lifecycle.PER_METHOD) semantics, a non-static @AutoClose field will be closed after the execution of each test method, test factory method, or test template method. However, if the test class is configured with @TestInstance(Lifecycle.PER_CLASS) semantics, a non-static @AutoClose field will not be closed until the current test class instance is no longer needed

Do you know what test class lifecycle is configured for test classes like this one when launched through jtreg?

Typically, we just use very basic JUnit constructs in the tests in the JDK repo to make it simpler to follow these tests, even if it means a bit more verbose code like having a method annotated with `@BeforeEach`/`@AfterEach` to do construction/clean up like this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2024629463

From jpai at openjdk.org  Wed Apr  2 11:49:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Apr 2025 11:49:55 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v5]
In-Reply-To: <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
Message-ID: <5ZtXn7Jo_a3Ru0StgJuR0NabpUNH-bcPeD-D5qWTHtY=.a0535a6e-b761-4f2e-ad68-62701ec69fa2@github.com>

On Tue, 1 Apr 2025 19:11:02 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review suggestions

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 156:

> 154:                                         "Server[%s] is waiting for the latch... (connectionKey=%s, responseBody=%s)",
> 155:                                         serverId, connectionKey, responseBody);
> 156:                                 assertTrue(serverResponseLatchRef[0].await(2, TimeUnit.SECONDS));

We should avoid using any kind of timeouts here and in other places where we call this `await(...)` in this test. Given how varied the test execution environments are and our past experience with such timeouts, there's no right timeout to choose from. Instead, we should just do a `await()` without the timeout, so that if for whatever reason the latch isn't counted down, then the jtreg test execution timeout (which is controlled and configured externally to the test) will kick in and jtreg will do the necessary work of failing the test and also gathering detailed diagnostics through any failure handlers that are configured in that test execution environment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2024659607

From alan.bateman at oracle.com  Wed Apr  2 12:20:28 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 2 Apr 2025 13:20:28 +0100
Subject: RFD: Query param discrepancy in unix/windows file
 Handler:openConnection
In-Reply-To: <CA+pBWhtbvbYfZvX1X0pSd5rO50iHfk2g2+1AZSUQCnFNP=DJ+w@mail.gmail.com>
References: <CA+pBWhtbvbYfZvX1X0pSd5rO50iHfk2g2+1AZSUQCnFNP=DJ+w@mail.gmail.com>
Message-ID: <4ae7066b-31a1-4a11-b1cf-37cf025350f5@oracle.com>



On 01/04/2025 20:09, Eirik Bj?rsn?s wrote:
> :
>
> Looking at the Windows implementation of 
> sun.net.protocol.www.file.Handler, it indeed uses URL::getFile when 
> constructing the file path, while the unix implementation uses 
> URL::getPath.
>
As a general point, neither method is correct when converting from a 
file URL to a file path. Much of the code here goes back to JDK 1.2 so 
we have to be careful with any changes.

-Alan

From rriggs at openjdk.org  Wed Apr  2 15:24:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 2 Apr 2025 15:24:54 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <3rUvTcaueXMF405h6x1PGklsHrtFw1-w6bxGFYk-hFI=.70207421-1812-4379-b429-361e044f4c64@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
 <be06ubYaB-uiTnXF43CatCTU0iaHw6xsmZKMEgInkrQ=.5856eff9-8b65-4283-9d21-8ccbd13b3ee3@github.com>
 <8ceX3GH_4y6Sscj3FThghTPymDVvzraLGQPd_xk-lp4=.7647fa31-8fe8-479c-8f10-9afa2ad37f62@github.com>
 <3rUvTcaueXMF405h6x1PGklsHrtFw1-w6bxGFYk-hFI=.70207421-1812-4379-b429-361e044f4c64@github.com>
Message-ID: <MsTK2A-VgHHGMDG2x9y0lmWIy2OFMJFhDZFvbQkinMI=.9f1f55f2-d07b-471f-be7a-cf5b73d39969@github.com>

On Wed, 2 Apr 2025 10:03:17 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> They are both NumberFormatException that is immediately handled by an enclosing catch block. This change should only affect the exception message for inputs fragments like %-F.
>
> Right. And `NumberFormatException` is a subclass of `IllegalArgumentException` so that would remain compatible even if it were not caught and replaced by plain IAE.

I pointed it out to emphasize that exceptions and exception messages should be considered and reviewed when making a change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24314#discussion_r2025073332

From eirbjo at gmail.com  Wed Apr  2 20:01:09 2025
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 2 Apr 2025 22:01:09 +0200
Subject: RFD: Query param discrepancy in unix/windows file
 Handler:openConnection
In-Reply-To: <4ae7066b-31a1-4a11-b1cf-37cf025350f5@oracle.com>
References: <CA+pBWhtbvbYfZvX1X0pSd5rO50iHfk2g2+1AZSUQCnFNP=DJ+w@mail.gmail.com>
 <4ae7066b-31a1-4a11-b1cf-37cf025350f5@oracle.com>
Message-ID: <CA+pBWht-Kft7AAOc=V0vB1uqja=WB=qxpkUqWjNfq=Z5g9SQtw@mail.gmail.com>

On Wed, Apr 2, 2025 at 2:20?PM Alan Bateman <alan.bateman at oracle.com> wrote:

As a general point, neither method is correct when converting from a
> file URL to a file path. Much of the code here goes back to JDK 1.2 so
> we have to be careful with any changes.
>

Thanks Alan & Daniel.

Yes, I agree that the value of "fixing" this issue seems low.

The context for looking into this was that this is one of two things that
is behaviorally different between the Handler implementations, all other
differences are strictly code style and formatting noise.

Before implementing JDK-8353440 to disable FTP fallback by default I might
want to look into refactoring the handlers such that they are syntactically
similar and that the actual platform specific differences are easier to
spot and document. Currently, it's a bit of a head-twister to figure out
how exactly they differ in behavior vs syntax.

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250402/94da7f6a/attachment.htm>

From duke at openjdk.org  Wed Apr  2 22:58:48 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Wed, 2 Apr 2025 22:58:48 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <6iw-4ZtRyZk_pvlMk8rUnb1epsRZU5fw4kFGxpmyIY8=.fc212512-cc7e-4b51-b927-6573849e3682@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
 <6iw-4ZtRyZk_pvlMk8rUnb1epsRZU5fw4kFGxpmyIY8=.fc212512-cc7e-4b51-b927-6573849e3682@github.com>
Message-ID: <abWf5vfty9NfZC8FTTMVBwalyS5RA8p7DurXRHMFugQ=.e3939edc-8f20-4d04-b243-555b598da1f4@github.com>

On Tue, 1 Apr 2025 17:25:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Interesting. Please run tier2 tests.

I've run the tier 2 tests locally and they pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/24314#issuecomment-2773910295

From dfuchs at openjdk.org  Thu Apr  3 10:14:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Apr 2025 10:14:58 GMT
Subject: RFR: 8353278: Consolidate local file URL checks in jar: and file:
 URL schemes
In-Reply-To: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
References: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
Message-ID: <__TC9Mcsm5nlLW2FZQB8_vjn6LfDR1jB1mK8SODSGQ8=.384f0d9d-acbc-40cc-a329-62b7464505df@github.com>

On Mon, 31 Mar 2025 14:46:32 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this cleanup PR which consolidates 'local file' URL checks across the 'file:' and 'jar:' URL scheme implementations and defines this check in terms of RFC 8089, Section 2.
> 
> This PR:
> 
> * Moves `URLJarFile.isFileURL` to `sun.net.www.ParseUtil` where it is documented according to RFC 8089 and given the more suitable name `isLocalFileURL`
> * Updates `isLocalFileURL` to simplify an `if (x) return true;` statement to `return x;`
> * Updates `URLJarFile.getJarFile` and `JarFileFactory.getOrCreate` to use `isLocalFileURL`
> * Updates `JarFileFactory.urlFor` to use `isLocalFileURL` (while maintaining and documenting the historical and subtly different non-treatment of '~' as an alias for 'localhost')
> * Updates `sun.net.www.protocol.file.Handler.openConnection` to use `isLocalFileURL` in windows/unix implementations
> 
> This is a pure cleanup / refactoring PR, no tests are updated here. Existing testing in this area seems sparse, so I have tried to limit the number of code tweaks to a minimium to make reviews easier.
> 
> Testing: GHA runs green, as well as tier2 on MacOS.

My tests came back green - but it wouldn't hurt to have another reviewer/committer eyeball these changes before integrating. As far as I could tell - the code with the new changes is strictly equivalent to the old.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24332#pullrequestreview-2739261233

From eirbjo at openjdk.org  Thu Apr  3 10:49:53 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 3 Apr 2025 10:49:53 GMT
Subject: RFR: 8353278: Consolidate local file URL checks in jar: and file:
 URL schemes
In-Reply-To: <__TC9Mcsm5nlLW2FZQB8_vjn6LfDR1jB1mK8SODSGQ8=.384f0d9d-acbc-40cc-a329-62b7464505df@github.com>
References: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
 <__TC9Mcsm5nlLW2FZQB8_vjn6LfDR1jB1mK8SODSGQ8=.384f0d9d-acbc-40cc-a329-62b7464505df@github.com>
Message-ID: <Mq30tHTOsJawRB4q9-2FZjPdoM6IT6oYouzpfKmbrDo=.ddd748dc-3a94-4c62-88eb-d447b798951e@github.com>

On Thu, 3 Apr 2025 10:12:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> My tests came back green - but it wouldn't hurt to have another reviewer/committer eyeball these changes before integrating. As far as I could tell - the code with the new changes is strictly equivalent to the old.

Thanks Daniel! 

I've tried performing changes rather mechanically and step-by-step, leaning on safe IDE refactorings where possible. But yes, would be great with a second pair of eyes! (@jaikiran is known to have great eyes!)

The two parts which may need focus is:

* To verify that `ParseUtil::isLocalFileURL` is indeeed equivalient to the old/removed `URLJarFile::isFileURL`.
* That the logic in `JarFileFactory::urlFor` survived the accomodations to use `ParseUtil::isLocalFileURL` (flipping (!=) to !(||), etc)

The remaining changes are of a more trivial kind.

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

PR Comment: https://git.openjdk.org/jdk/pull/24332#issuecomment-2775312586

From abarashev at openjdk.org  Thu Apr  3 20:33:55 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 3 Apr 2025 20:33:55 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v3]
In-Reply-To: <NfKVswsgmqoFm08V5OCTIlVEU34w1UgP5jyzAexDekA=.54ff82f5-dd56-4f86-abf6-325fab333724@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <NfKVswsgmqoFm08V5OCTIlVEU34w1UgP5jyzAexDekA=.54ff82f5-dd56-4f86-abf6-325fab333724@github.com>
Message-ID: <AIm5JTr_STaj_hhKToFS8m3g0JI0QRJPPjtR15Q_8VM=.6de492ae-3560-41d4-a573-81d2ccebeee2@github.com>

On Tue, 18 Mar 2025 14:58:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
>> 
>> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
>> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
>> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - reversed order of DN strings when making certificates.
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - changed boolean array initialization
>  - 8325766: Review seclibs tests for cert expiry

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 243:

> 241:                 .addBasicConstraintsExt(false, false, -1)
> 242:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))
> 243:                 .build(trustedCert, caKeys.getPrivate(), "MD5WithRSA");

MD5 algorithm is not allowed in TLSv1.3

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 255:

> 253:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))
> 254:                 .addBasicConstraintsExt(false, false, -1)
> 255:                 .build(trustedCert, caKeys.getPrivate(), "MD5WithRSA");

Same as above: MD5 algorithm is not allowed in TLSv1.3 certificates

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2027699283
PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2027699952

From eirbjo at openjdk.org  Fri Apr  4 04:51:12 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 4 Apr 2025 04:51:12 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP
Message-ID: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>

Please review this test-only PR which introduces testing of the unspecified but long-standing fallback to FTP for non-local files in the 'file' URL scheme. 

This in preparation for the upcoming proposal to disable the feature by default in JDK-8353440.

Since we cannot reliably bind an FTP server to port 21, the test instead uses an HTTP proxy, binding to an ephemeral port. This menas we don't test non-proxy code paths. We still test that the FTP fallback is used, which is the key point here. (We aim to test file URL connections, not FTP URL connection internals) 

An alternative here could be to just verify that the returned URLConnection is an instance of FtpURLConnection. However, I opted for an end-to-end test here, since the amount of extra code seems reasonable.

By temporarly moving this test to tier1, I was able to confirm this test runs green also on Windows GHA.

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

Commit messages:
 - Add a test verifying non-local file: URL fallback to FTP

Changes: https://git.openjdk.org/jdk/pull/24418/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24418&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353662
  Stats: 141 lines in 1 file changed: 141 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24418.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24418/head:pull/24418

PR: https://git.openjdk.org/jdk/pull/24418

From duke at openjdk.org  Fri Apr  4 06:27:24 2025
From: duke at openjdk.org (Tabata Daishi)
Date: Fri, 4 Apr 2025 06:27:24 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the console's
 encoding is not UTF-8
Message-ID: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>

The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.

The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.

I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.

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

Commit messages:
 - Update copyright
 - Fix garbled characters in simple web server

Changes: https://git.openjdk.org/jdk/pull/24437/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24437&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353698
  Stats: 65 lines in 10 files changed: 9 ins; 3 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/24437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24437/head:pull/24437

PR: https://git.openjdk.org/jdk/pull/24437

From duke at openjdk.org  Fri Apr  4 06:47:02 2025
From: duke at openjdk.org (Tabata Daishi)
Date: Fri, 4 Apr 2025 06:47:02 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v2]
In-Reply-To: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
Message-ID: <O3IW55bjzRD-j258RVqDV5A-ek8XMYyTYVi9gcB_QjE=.6846892b-b593-4f12-928c-c525ce1089d4@github.com>

> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
> 
> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
> 
> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.

Tabata Daishi has updated the pull request incrementally with one additional commit since the last revision:

  run jcheck

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24437/files
  - new: https://git.openjdk.org/jdk/pull/24437/files/7e149b6f..427cbe4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24437&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24437&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24437/head:pull/24437

PR: https://git.openjdk.org/jdk/pull/24437

From djelinski at openjdk.org  Fri Apr  4 08:01:48 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 4 Apr 2025 08:01:48 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v2]
In-Reply-To: <O3IW55bjzRD-j258RVqDV5A-ek8XMYyTYVi9gcB_QjE=.6846892b-b593-4f12-928c-c525ce1089d4@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <O3IW55bjzRD-j258RVqDV5A-ek8XMYyTYVi9gcB_QjE=.6846892b-b593-4f12-928c-c525ce1089d4@github.com>
Message-ID: <w3MAvAdSHYgpp64Fd4YmR_Ikr-szvzth2PWC7nRmEP4=.f75a6c8f-ddd7-4f77-90f4-46d24198d5c3@github.com>

On Fri, 4 Apr 2025 06:47:02 GMT, Tabata Daishi <duke at openjdk.org> wrote:

>> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
>> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
>> 
>> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
>> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
>> 
>> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
>> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.
>
> Tabata Daishi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run jcheck

LGTM. Thank you for addressing the issues!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24437#pullrequestreview-2742149689

From duke at openjdk.org  Fri Apr  4 09:13:30 2025
From: duke at openjdk.org (Daishi Tabata)
Date: Fri, 4 Apr 2025 09:13:30 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
Message-ID: <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>

> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
> 
> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
> 
> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.

Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24437/files
  - new: https://git.openjdk.org/jdk/pull/24437/files/427cbe4b..0bc8e196

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24437&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24437&range=01-02

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24437/head:pull/24437

PR: https://git.openjdk.org/jdk/pull/24437

From eirbjo at openjdk.org  Fri Apr  4 10:28:57 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 4 Apr 2025 10:28:57 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v2]
In-Reply-To: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
Message-ID: <PHxV7hdz3tTQwkL77RWZQjywGB2Catn0zWodW7c6Pw0=.34fb4891-6b6a-48a4-bca5-50e5778d0d8f@github.com>

> Please review this test-only PR which introduces testing of the unspecified but long-standing fallback to FTP for non-local files in the 'file' URL scheme. 
> 
> This in preparation for the upcoming proposal to disable the feature by default in JDK-8353440.
> 
> Since we cannot reliably bind an FTP server to port 21, the test instead uses an HTTP proxy, binding to an ephemeral port. This menas we don't test non-proxy code paths. We still test that the FTP fallback is used, which is the key point here. (We aim to test file URL connections, not FTP URL connection internals) 
> 
> An alternative here could be to just verify that the returned URLConnection is an instance of FtpURLConnection. However, I opted for an end-to-end test here, since the amount of extra code seems reasonable.
> 
> By temporarly moving this test to tier1, I was able to confirm this test runs green also on Windows GHA.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Do not assume that the loopback address is IPv4

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24418/files
  - new: https://git.openjdk.org/jdk/pull/24418/files/f235d79f..18b449de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24418&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24418&range=00-01

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24418.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24418/head:pull/24418

PR: https://git.openjdk.org/jdk/pull/24418

From eirbjo at openjdk.org  Fri Apr  4 10:28:59 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 4 Apr 2025 10:28:59 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v2]
In-Reply-To: <TQDE-jCNJuKObJLUhsRqwng_zvBH1wG27YpDCegxoqA=.74c9703f-4ae2-4015-a573-c039787783b5@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <PHxV7hdz3tTQwkL77RWZQjywGB2Catn0zWodW7c6Pw0=.34fb4891-6b6a-48a4-bca5-50e5778d0d8f@github.com>
 <TQDE-jCNJuKObJLUhsRqwng_zvBH1wG27YpDCegxoqA=.74c9703f-4ae2-4015-a573-c039787783b5@github.com>
Message-ID: <PFuU80VhHUdAESyK6BvIQOv4qqvXi7H_LndYzxKnT-Y=.7ae28607-bd8d-47c9-a5d6-881d5eb3e49d@github.com>

On Fri, 4 Apr 2025 10:19:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The URL should not assume that the loopback is an IPv4 address. Or is this handled by the proxy?

Right. The following returns "127.0.0.1" for me, would that be the correct API to use?

`InetAddress.getLoopbackAddress().getHostAddress()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24418#discussion_r2028548480

From dfuchs at openjdk.org  Fri Apr  4 10:28:59 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 10:28:59 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v2]
In-Reply-To: <PFuU80VhHUdAESyK6BvIQOv4qqvXi7H_LndYzxKnT-Y=.7ae28607-bd8d-47c9-a5d6-881d5eb3e49d@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <PHxV7hdz3tTQwkL77RWZQjywGB2Catn0zWodW7c6Pw0=.34fb4891-6b6a-48a4-bca5-50e5778d0d8f@github.com>
 <TQDE-jCNJuKObJLUhsRqwng_zvBH1wG27YpDCegxoqA=.74c9703f-4ae2-4015-a573-c039787783b5@github.com>
 <PFuU80VhHUdAESyK6BvIQOv4qqvXi7H_LndYzxKnT-Y=.7ae28607-bd8d-47c9-a5d6-881d5eb3e49d@github.com>
Message-ID: <eoSQ5kmLLbbgnrAgX0i-XFtZppOGur87qZyvqb4TIFU=.356a6b8a-25f6-401b-88ae-139d0bae8074@github.com>

On Fri, 4 Apr 2025 10:24:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> test/jdk/sun/net/www/protocol/file/NonLocalFtpFallback.java line 122:
>> 
>>> 120:     public void verifyNonLocalFtpFallback() throws Exception {
>>> 121:         URL localURL = file.toUri().toURL();
>>> 122:         URL nonLocalURL = new URL("file", "127.0.0.1", localURL.getFile());
>> 
>> The URL should not assume that the loopback is an IPv4 address. Or is this handled by the proxy?
>
>> The URL should not assume that the loopback is an IPv4 address. Or is this handled by the proxy?
> 
> Right. The following returns "127.0.0.1" for me, would that be the correct API to use?
> 
> `InetAddress.getLoopbackAddress().getHostAddress()`

Ok - I see that 127.0.0.1 should not be directly used. Would it work if we replaced that with a fake host name then?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24418#discussion_r2028549245

From eirbjo at openjdk.org  Fri Apr  4 10:33:48 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 4 Apr 2025 10:33:48 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v2]
In-Reply-To: <eoSQ5kmLLbbgnrAgX0i-XFtZppOGur87qZyvqb4TIFU=.356a6b8a-25f6-401b-88ae-139d0bae8074@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <PHxV7hdz3tTQwkL77RWZQjywGB2Catn0zWodW7c6Pw0=.34fb4891-6b6a-48a4-bca5-50e5778d0d8f@github.com>
 <TQDE-jCNJuKObJLUhsRqwng_zvBH1wG27YpDCegxoqA=.74c9703f-4ae2-4015-a573-c039787783b5@github.com>
 <PFuU80VhHUdAESyK6BvIQOv4qqvXi7H_LndYzxKnT-Y=.7ae28607-bd8d-47c9-a5d6-881d5eb3e49d@github.com>
 <eoSQ5kmLLbbgnrAgX0i-XFtZppOGur87qZyvqb4TIFU=.356a6b8a-25f6-401b-88ae-139d0bae8074@github.com>
Message-ID: <iyRsR0pzra--OWcc7ox8wzURZJXz0n9xmN-_E33Kd1I=.4af9b40e-85b0-4b4e-90a5-a0603b7a3ca8@github.com>

On Fri, 4 Apr 2025 10:25:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Ok - I see that 127.0.0.1 should not be directly used. Would it work if we replaced that with a fake host name then?

Yeah, you're right, the FTP request never materializes (our proxy just swallows it). So we only use it to assert against what was requested from the proxy, we can use a fake host name.

Any preference/precedence for fake host names?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24418#discussion_r2028557214

From dfuchs at openjdk.org  Fri Apr  4 10:28:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 10:28:58 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v2]
In-Reply-To: <PHxV7hdz3tTQwkL77RWZQjywGB2Catn0zWodW7c6Pw0=.34fb4891-6b6a-48a4-bca5-50e5778d0d8f@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <PHxV7hdz3tTQwkL77RWZQjywGB2Catn0zWodW7c6Pw0=.34fb4891-6b6a-48a4-bca5-50e5778d0d8f@github.com>
Message-ID: <TQDE-jCNJuKObJLUhsRqwng_zvBH1wG27YpDCegxoqA=.74c9703f-4ae2-4015-a573-c039787783b5@github.com>

On Fri, 4 Apr 2025 10:25:35 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this test-only PR which introduces testing of the unspecified but long-standing fallback to FTP for non-local files in the 'file' URL scheme. 
>> 
>> This in preparation for the upcoming proposal to disable the feature by default in JDK-8353440.
>> 
>> Since we cannot reliably bind an FTP server to port 21, the test instead uses an HTTP proxy, binding to an ephemeral port. This menas we don't test non-proxy code paths. We still test that the FTP fallback is used, which is the key point here. (We aim to test file URL connections, not FTP URL connection internals) 
>> 
>> An alternative here could be to just verify that the returned URLConnection is an instance of FtpURLConnection. However, I opted for an end-to-end test here, since the amount of extra code seems reasonable.
>> 
>> By temporarly moving this test to tier1, I was able to confirm this test runs green also on Windows GHA.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not assume that the loopback address is IPv4

test/jdk/sun/net/www/protocol/file/NonLocalFtpFallback.java line 122:

> 120:     public void verifyNonLocalFtpFallback() throws Exception {
> 121:         URL localURL = file.toUri().toURL();
> 122:         URL nonLocalURL = new URL("file", "127.0.0.1", localURL.getFile());

The URL should not assume that the loopback is an IPv4 address. Or is this handled by the proxy?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24418#discussion_r2028542481

From eirbjo at openjdk.org  Fri Apr  4 10:37:58 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 4 Apr 2025 10:37:58 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v3]
In-Reply-To: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
Message-ID: <6-DH9HLfhkXR0RazrHG_p668w9lsykybwNh_KrxELt8=.eab8b548-9025-4e4a-85bf-4590b50bd34d@github.com>

> Please review this test-only PR which introduces testing of the unspecified but long-standing fallback to FTP for non-local files in the 'file' URL scheme. 
> 
> This in preparation for the upcoming proposal to disable the feature by default in JDK-8353440.
> 
> Since we cannot reliably bind an FTP server to port 21, the test instead uses an HTTP proxy, binding to an ephemeral port. This menas we don't test non-proxy code paths. We still test that the FTP fallback is used, which is the key point here. (We aim to test file URL connections, not FTP URL connection internals) 
> 
> An alternative here could be to just verify that the returned URLConnection is an instance of FtpURLConnection. However, I opted for an end-to-end test here, since the amount of extra code seems reasonable.
> 
> By temporarly moving this test to tier1, I was able to confirm this test runs green also on Windows GHA.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Use a fake host name since no actual FTP request will be attempted

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24418/files
  - new: https://git.openjdk.org/jdk/pull/24418/files/18b449de..049bb5fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24418&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24418&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24418.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24418/head:pull/24418

PR: https://git.openjdk.org/jdk/pull/24418

From dfuchs at openjdk.org  Fri Apr  4 10:39:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 10:39:58 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
Message-ID: <j_HGo86rodeY9JEd9l4PGe_DkTM3c7HwBHvGbPEOAA0=.7cb94ac7-0aa8-488c-bddf-c1ca1be21483@github.com>

On Fri, 4 Apr 2025 09:13:30 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
>> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
>> 
>> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
>> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
>> 
>> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
>> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

Hi, it's not completely clear to me why `static final String LOCALE_OPT = "-Duser.language=en -Duser.country=US";` has now to be passed to every test that checks command line options. Is that a separate unrelated test fix?

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

PR Comment: https://git.openjdk.org/jdk/pull/24437#issuecomment-2778274565

From eirbjo at openjdk.org  Fri Apr  4 10:42:54 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 4 Apr 2025 10:42:54 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v3]
In-Reply-To: <6-DH9HLfhkXR0RazrHG_p668w9lsykybwNh_KrxELt8=.eab8b548-9025-4e4a-85bf-4590b50bd34d@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <6-DH9HLfhkXR0RazrHG_p668w9lsykybwNh_KrxELt8=.eab8b548-9025-4e4a-85bf-4590b50bd34d@github.com>
Message-ID: <l3gqcoXa9N3HUjt0aBQZuEqHLV3hHxEGHoF0wAqBFKo=.5d438fee-f0e5-40a5-8019-f462da542603@github.com>

On Fri, 4 Apr 2025 10:37:58 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this test-only PR which introduces testing of the unspecified but long-standing fallback to FTP for non-local files in the 'file' URL scheme. 
>> 
>> This in preparation for the upcoming proposal to disable the feature by default in JDK-8353440.
>> 
>> Since we cannot reliably bind an FTP server to port 21, the test instead uses an HTTP proxy, binding to an ephemeral port. This menas we don't test non-proxy code paths. We still test that the FTP fallback is used, which is the key point here. (We aim to test file URL connections, not FTP URL connection internals) 
>> 
>> An alternative here could be to just verify that the returned URLConnection is an instance of FtpURLConnection. However, I opted for an end-to-end test here, since the amount of extra code seems reasonable.
>> 
>> By temporarly moving this test to tier1, I was able to confirm this test runs green also on Windows GHA.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a fake host name since no actual FTP request will be attempted

@dfuch Tagnential observation: `proxyServer.stop(2)` will always wait 2 seconds here. I was assuming it would only do that if there was an ongoing exchange.

Looking at the `ServerImpl` class, it looks like `finished` is never set to true. Specifically, `ServerImpl.Dispatcher::handleEvent` does not set it to true since that happens before `terminating` is set to true.

How is `HttpServer::stop` expected to work? Is something wrong with my expectations that this should return quickly with no inflight exchanges?

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

PR Comment: https://git.openjdk.org/jdk/pull/24418#issuecomment-2778281722

From vyazici at openjdk.org  Fri Apr  4 10:44:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 4 Apr 2025 10:44:28 GMT
Subject: RFR: 8351339: WebSocket::sendBinary assume that user supplied
 buffers are BIG_ENDIAN [v8]
In-Reply-To: <DZNj1tQz990jOnUOIoik2387TGm8btL_IE1UfGHa1PU=.b039c500-6a30-4757-83f4-7825ea86c3a7@github.com>
References: <DZNj1tQz990jOnUOIoik2387TGm8btL_IE1UfGHa1PU=.b039c500-6a30-4757-83f4-7825ea86c3a7@github.com>
Message-ID: <u-GM635NAS-VswbJCA3JpTeeY7GDLY-HStqqDS9HiUM=.9a4948c1-d94e-4fda-9dc8-143af4846446@github.com>

> Fixes endian handling `jdk.internal.net.http.websocket.Frame.Masker`.
> 
> ### Implementation notes
> 
> I deleted the `Frame` clone in tests, and rewired the test code depending on it to the actual `Frame`. To enable this, I relaxed the visibility of the actual `Frame`. I guess the `Frame` clone was introduced to have strict visibility in the actual `Frame`. Though this is not needed since the actual `Frame` is in an internal package. Plus, the fact that bug is in the `Frame` class hints in the direction that there should be one `Frame`.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Use negative `byte` values in tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24033/files
  - new: https://git.openjdk.org/jdk/pull/24033/files/41b40436..e0981109

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24033&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24033&range=06-07

  Stats: 34 lines in 1 file changed: 17 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24033/head:pull/24033

PR: https://git.openjdk.org/jdk/pull/24033

From dfuchs at openjdk.org  Fri Apr  4 10:50:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 10:50:57 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v3]
In-Reply-To: <iyRsR0pzra--OWcc7ox8wzURZJXz0n9xmN-_E33Kd1I=.4af9b40e-85b0-4b4e-90a5-a0603b7a3ca8@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <PHxV7hdz3tTQwkL77RWZQjywGB2Catn0zWodW7c6Pw0=.34fb4891-6b6a-48a4-bca5-50e5778d0d8f@github.com>
 <TQDE-jCNJuKObJLUhsRqwng_zvBH1wG27YpDCegxoqA=.74c9703f-4ae2-4015-a573-c039787783b5@github.com>
 <PFuU80VhHUdAESyK6BvIQOv4qqvXi7H_LndYzxKnT-Y=.7ae28607-bd8d-47c9-a5d6-881d5eb3e49d@github.com>
 <eoSQ5kmLLbbgnrAgX0i-XFtZppOGur87qZyvqb4TIFU=.356a6b8a-25f6-401b-88ae-139d0bae8074@github.com>
 <iyRsR0pzra--OWcc7ox8wzURZJXz0n9xmN-_E33Kd1I=.4af9b40e-85b0-4b4e-90a5-a0603b7a3ca8@github.com>
Message-ID: <poFJi6yAGv-ncgCC0U17egyN1tKuS-31499oYFFOj4w=.fa7128f6-fef2-469b-a994-d7faceda2684@github.com>

On Fri, 4 Apr 2025 10:31:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Ok - I see that 127.0.0.1 should not be directly used. Would it work if we replaced that with a fake host name then?
>
>> Ok - I see that 127.0.0.1 should not be directly used. Would it work if we replaced that with a fake host name then?
> 
> Yeah, you're right, the FTP request never materializes (our proxy just swallows it). So we only use it to assert against what was requested from the proxy, we can use a fake host name.
> 
> Any preference/precedence for fake host names?

Generally looks good. "127.0.0.1" rings alarm bells because we're trying to make our tests independent of the IP versions supported by the machine they run on.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24418#discussion_r2028577797

From dfuchs at openjdk.org  Fri Apr  4 11:02:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 11:02:15 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v3]
In-Reply-To: <l3gqcoXa9N3HUjt0aBQZuEqHLV3hHxEGHoF0wAqBFKo=.5d438fee-f0e5-40a5-8019-f462da542603@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <6-DH9HLfhkXR0RazrHG_p668w9lsykybwNh_KrxELt8=.eab8b548-9025-4e4a-85bf-4590b50bd34d@github.com>
 <l3gqcoXa9N3HUjt0aBQZuEqHLV3hHxEGHoF0wAqBFKo=.5d438fee-f0e5-40a5-8019-f462da542603@github.com>
Message-ID: <1KacRQ9ZB8kBDOvYQTLoDBBInHWHYLC3xGYx12IWGWU=.ed72c5b3-96e2-415d-b254-8913f8faae7f@github.com>

On Fri, 4 Apr 2025 10:40:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> @dfuch Tagnential observation: `proxyServer.stop(2)` will always wait 2 seconds here. I was assuming it would only do that if there was an ongoing exchange.
> 
> Looking at the `ServerImpl` class, it looks like `finished` is never set to true. Specifically, `ServerImpl.Dispatcher::handleEvent` does not set it to true since that happens before `terminating` is set to true.
> 
> How is `HttpServer::stop` expected to work? Is something wrong with my expectations that this should return quickly with no inflight exchanges?

Interesting. That looks like a bug to me. stop() should probably look at `exchangeCount` too - but that will require some thinking to get the asynchronous stops to work correctly. Should be worth logging a bug :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/24418#issuecomment-2778350297

From eirbjo at openjdk.org  Fri Apr  4 11:08:47 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 4 Apr 2025 11:08:47 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v3]
In-Reply-To: <1KacRQ9ZB8kBDOvYQTLoDBBInHWHYLC3xGYx12IWGWU=.ed72c5b3-96e2-415d-b254-8913f8faae7f@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <6-DH9HLfhkXR0RazrHG_p668w9lsykybwNh_KrxELt8=.eab8b548-9025-4e4a-85bf-4590b50bd34d@github.com>
 <l3gqcoXa9N3HUjt0aBQZuEqHLV3hHxEGHoF0wAqBFKo=.5d438fee-f0e5-40a5-8019-f462da542603@github.com>
 <1KacRQ9ZB8kBDOvYQTLoDBBInHWHYLC3xGYx12IWGWU=.ed72c5b3-96e2-415d-b254-8913f8faae7f@github.com>
Message-ID: <gdb6MKf2mXmS-cwxpx1afwIQwAQezH1pLOYuIBvJCqU=.8ed8e125-f5d8-431b-9a45-587cc57e82b2@github.com>

On Fri, 4 Apr 2025 10:58:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Interesting. That looks like a bug to me. stop() should probably look at `exchangeCount` too - but that will require some thinking to get the asynchronous stops to work correctly. Should be worth logging a bug :-)

Let's see if this captures the essence:

https://bugs.openjdk.org/browse/JDK-8353720

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

PR Comment: https://git.openjdk.org/jdk/pull/24418#issuecomment-2778368216

From duke at openjdk.org  Fri Apr  4 11:20:55 2025
From: duke at openjdk.org (Daishi Tabata)
Date: Fri, 4 Apr 2025 11:20:55 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <j_HGo86rodeY9JEd9l4PGe_DkTM3c7HwBHvGbPEOAA0=.7cb94ac7-0aa8-488c-bddf-c1ca1be21483@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
 <j_HGo86rodeY9JEd9l4PGe_DkTM3c7HwBHvGbPEOAA0=.7cb94ac7-0aa8-488c-bddf-c1ca1be21483@github.com>
Message-ID: <38dt8yjyudQU_-Afy1xhqEzQXjEeEtn5-1w6qw0wB0o=.a7cb8662-f5da-46b7-a892-c2191b76f4d6@github.com>

On Fri, 4 Apr 2025 10:36:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update full name
>
> Hi, it's not completely clear to me why `static final String LOCALE_OPT = "-Duser.language=en -Duser.country=US";` has now to be passed to every test that checks command line options. Is that a separate unrelated test fix?

@dfuch Thank you for your comment.
> Is that a separate unrelated test fix?

No, it's related.

For example, after this modification, if you run `jwebserver --help` on Japanese Windows without specifying a locale, it will be output in Japanese as follows:


> jwebserver.exe --help
????: jwebserver [-b bind address] [-p port] [-d directory]
                  [-o none|info|verbose] [-h to show options]
                  [-version to show version information]
?????:
-b, --bind-address    - ???????????????: 127.0.0.1 (??????)?
                        ????????????"-b 0.0.0.0"???"-b ::"???????
-d, --directory       - ????????????????: ??????????
-o, --output          - ?????none|info|verbose??????: info?
-p, --port            - ????????????????: 8000?
-h, -?, --help        - ????????????????????
-version, --version   - ??????????????????
????????????[Ctrl]+[C]??????


This is the same in jtreg tests, so if you test it on Japanese Windows, it will fail.
By specifying the English locale to `jwebserver` or `java -m jdk.httpserver`, you can get English output even on Japanese Windows, so the test will be Passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/24437#issuecomment-2778391933

From jpai at openjdk.org  Fri Apr  4 11:22:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Apr 2025 11:22:59 GMT
Subject: RFR: 8353278: Consolidate local file URL checks in jar: and file:
 URL schemes
In-Reply-To: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
References: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
Message-ID: <iKtx4zRiZPHGhBpubew8-bp41vtFYEtLfNn7hI2uXBA=.fdd15504-d933-48ae-878d-aff8917afec8@github.com>

On Mon, 31 Mar 2025 14:46:32 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this cleanup PR which consolidates 'local file' URL checks across the 'file:' and 'jar:' URL scheme implementations and defines this check in terms of RFC 8089, Section 2.
> 
> This PR:
> 
> * Moves `URLJarFile.isFileURL` to `sun.net.www.ParseUtil` where it is documented according to RFC 8089 and given the more suitable name `isLocalFileURL`
> * Updates `isLocalFileURL` to simplify an `if (x) return true;` statement to `return x;`
> * Updates `URLJarFile.getJarFile` and `JarFileFactory.getOrCreate` to use `isLocalFileURL`
> * Updates `JarFileFactory.urlFor` to use `isLocalFileURL` (while maintaining and documenting the historical and subtly different non-treatment of '~' as an alias for 'localhost')
> * Updates `sun.net.www.protocol.file.Handler.openConnection` to use `isLocalFileURL` in windows/unix implementations
> 
> This is a pure cleanup / refactoring PR, no tests are updated here. Existing testing in this area seems sparse, so I have tried to limit the number of code tweaks to a minimium to make reviews easier.
> 
> Testing: GHA runs green, as well as tier2 on MacOS.

Hello Eirik, I'll take a look at the PR shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/24332#issuecomment-2778394828

From duke at openjdk.org  Fri Apr  4 11:30:49 2025
From: duke at openjdk.org (Daishi Tabata)
Date: Fri, 4 Apr 2025 11:30:49 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
Message-ID: <wiXiSvM6l75XzkgN4uPfKbxAvbyWsQIWTtMIRh6gsOU=.9e42acdc-0bf7-4b2d-96ff-8fcb1d19273f@github.com>

On Fri, 4 Apr 2025 09:13:30 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
>> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
>> 
>> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
>> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
>> 
>> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
>> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

Upon reconsideration, these tests were failing on Japanese Windows even before the fix.
Should I issue a separate Bug ID?

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

PR Comment: https://git.openjdk.org/jdk/pull/24437#issuecomment-2778421156

From vyazici at openjdk.org  Fri Apr  4 12:04:01 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 4 Apr 2025 12:04:01 GMT
Subject: RFR: 8351339: WebSocket::sendBinary assume that user supplied
 buffers are BIG_ENDIAN [v4]
In-Reply-To: <O2TvH0a0Yy_CLNQ4FVNxN7-0fJs39eAKX35Su-bsCC0=.0230dfdf-a483-48a6-a255-ce4171568729@github.com>
References: <DZNj1tQz990jOnUOIoik2387TGm8btL_IE1UfGHa1PU=.b039c500-6a30-4757-83f4-7825ea86c3a7@github.com>
 <Ah9eH9Mi2uVz_rokBFwxpPqJRt6C3JgcW87r68YubIM=.8c43d8ca-7064-4c48-b7bc-76b510a2bb6a@github.com>
 <O2TvH0a0Yy_CLNQ4FVNxN7-0fJs39eAKX35Su-bsCC0=.0230dfdf-a483-48a6-a255-ce4171568729@github.com>
Message-ID: <WczkSg0caOetBzJ4QJYzRJEGmvfdT1NRNplMAkh6oUU=.e9dac3b2-6703-4a03-a431-19832850b9ea@github.com>

On Thu, 20 Mar 2025 13:55:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review feedback on naming in `Masker`
>>   
>>   `reset` -> `setMask`
>>   `initGallopingMask` -> `initVectorMask`
>>   `applyGallopingMask` -> `applyVectorMask`
>
>> Hi, original filer here. I don't know how you handle such things here, but 24 files changed seems somewhat excessive to me for this bug.
>> 
>> I do not know how effective the long-optimization realy is because/when data is not 8-byte-aligned. But if one wants to implement it, be sure to apply _native_ endianess for the mask-long, the input (eg. via a slice) and the buffer. If one uses the java default big endian (aaargh...), and "happens" to run on a little endian machine, the "optimization" would have to do a byte swap to native endian on read, do the masking and byteswap again on the way out. (same is true when choosing little endian and running on big endian hardware, although i would like the chances there much better ;-))
> 
> I don't think alignment is an issue here at all. `ByteBuffer.getLong()` does not have any alignment constraints on the underlying memory. There's no way to know if it is 8-byte aligned afaict. The first 8 bytes (and every subsequent 8 bytes) can be read as a long (subject to this byte ordering issue). The final chunk of up to 7 bytes is then handled byte at a time.
> 
> To add to that; it's probably still true that the optimization would not be very effective if the buffers are not 8 (or at least 4) byte aligned, but there's no way to guarantee it.
> 
> I'm not sure what (if any) difference the platform's native byte order has either for that matter.

@Michael-Mc-Mahon, after having a conversation with @dfuch, I've expanded the tests to cover cases where negative `byte` values are present both in the mask and the in the input buffer to be masked. I'd appreciate your final review, and if you don't have any objections, approval, please.

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

PR Comment: https://git.openjdk.org/jdk/pull/24033#issuecomment-2778488190

From dfuchs at openjdk.org  Fri Apr  4 12:33:07 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 12:33:07 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
Message-ID: <4PGdYvXE5L7RORupCk5_lD5YsEARVWiWEUI7R18-UmU=.50993aee-6e05-4226-874a-ae7e73d8e943@github.com>

On Fri, 4 Apr 2025 09:13:30 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
>> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
>> 
>> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
>> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
>> 
>> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
>> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

> Upon reconsideration, these tests were failing on Japanese Windows even before the fix.
> Should I issue a separate Bug ID?

That's what I suspected. I just wanted to make sure that needing the locale was not a side effect of your changes.
That said - I believe our tests are typically expecting the CI system (or make)? to set Locale.ENGLISH before running the tests.

I'm good with the changes you're proposing. Please hold on integrating for a bit - I would like to verify that there no regression in our CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/24437#issuecomment-2778586005

From rriggs at openjdk.org  Fri Apr  4 12:44:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 12:44:03 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for removal
Message-ID: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>

Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission

@Deprecated(forRemoval = true, since="25")
Is added to each class and the existing @apiNote is converted to @deprected

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

Commit messages:
 - 8353641: Deprecate core library permission classes for removal

Changes: https://git.openjdk.org/jdk/pull/24444/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353641
  Stats: 47 lines in 15 files changed: 28 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From vyazici at openjdk.org  Fri Apr  4 12:47:19 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 4 Apr 2025 12:47:19 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v5]
In-Reply-To: <T2_pjr7dnQhf3rIQxtu18pBwW5xa6YR6QRso6VM4vV4=.a054f9a5-8794-476b-be52-c7dec6d608e7@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
 <T2_pjr7dnQhf3rIQxtu18pBwW5xa6YR6QRso6VM4vV4=.a054f9a5-8794-476b-be52-c7dec6d608e7@github.com>
Message-ID: <1YpYh04Ig0EhdbBRaC2rslSP24t6SLtE_bIHrGKYo1U=.70f2cac0-24b5-45ef-9a6d-9ccba8546def@github.com>

On Wed, 2 Apr 2025 11:10:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review suggestions
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java line 100:
> 
>> 98:      * {@link PlainHttpConnection} it wraps will share the same label. As a
>> 99:      * result, compared to {@link #id}, this label does not give a total order
>> 100:      * among instances.
> 
> Suggestion:
> 
>     /**
>      * A label to identify the connection.
>      * <p>
>      * This label helps with associating multiple components participating in a
>      * connection. For instance, an {@link AsyncSSLConnection} and the
>      * {@link PlainHttpConnection} it wraps will share the same label.

Implemented in 42ff0fc4a83cd33f1a35e4a2b3e7ce5c25ea39cc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028746945

From vyazici at openjdk.org  Fri Apr  4 12:47:19 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 4 Apr 2025 12:47:19 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
Message-ID: <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>

> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
> 
> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.

Volkan Yazici has updated the pull request incrementally with five additional commits since the last revision:

 - Remove timeout from `CountDownLatch::await` calls
 - Replace `@AutoClose` with a corresponding `@AfterEach` method
 - Remove IDE-specific `OptionalGetWithoutIsPresent` warning suppression
 - Improve `HttpConnection::label` JavaDoc
 - Start from 1 while labeling connections

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24154/files
  - new: https://git.openjdk.org/jdk/pull/24154/files/883135d8..5b418fd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=04-05

  Stats: 16 lines in 2 files changed: 6 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24154/head:pull/24154

PR: https://git.openjdk.org/jdk/pull/24154

From vyazici at openjdk.org  Fri Apr  4 12:47:19 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 4 Apr 2025 12:47:19 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v4]
In-Reply-To: <wC4xX-6dhx8lOAZu4okoyoNsULjWv_idxtthcaFA7jQ=.3f00f4a4-b562-45b6-aa8f-010ec8b3a2e6@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <tAIXaR9JwJp5BPPLXFmao8eS-gRZj_Wm7c9v369IZ5I=.515939fe-d758-4188-838e-554817c12a10@github.com>
 <JL_I4s2qV2FBXgU48la2-xEyM0aXG5_1kRBBokwvGPg=.c4b5c511-1689-4794-aca7-b3360ef022f3@github.com>
 <KnRTrwmtR707Xgo50S7qF2rzRgQGIX_dvdzoVKn2dcA=.b43f1408-82a8-4fb4-a4a1-b64317c70aba@github.com>
 <XnpajXgUNOALWeMng5oyyPFtCjPRpQxrehDmG8WE9Es=.2fc8fe49-7b53-45b2-a6a4-aec1c0a51371@github.com>
 <nOQVYBkgi0EshKDd0slX5uYcv-1tK0OwQ-PI8ZvRO_A=.b4a1abe3-e892-4964-8146-0cedee3ec861@github.com>
 <MPh890s_cpVmaes8gA0ks9dOWjdqr27tEia1lLRRU4I=.b40c379d-b1c9-4004-bbe3-ecf9a0887399@github.com>
 <GAgpUeiPWdjNHUL3MTOqI1uEVAwbCBU2lv-1lO6748A=.926ab91b-a454-4121-bcf8-fe1fe2561eaa@github.com>
 <wC4xX-6dhx8lOAZu4okoyoNsULjWv_idxtthcaFA7jQ=.3f00f4a4-b562-45b6-aa8f-010ec8b3a2e6@github.com>
Message-ID: <LFJjBqKA6pCdawsIy6wa7G1SEm5NEdLiA6dZXJKalqk=.81370546-20dd-4baa-ab22-ab06d55ce054@github.com>

On Wed, 2 Apr 2025 11:10:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hello Volkan, I think having the mention of ordering on the `id` field is OK. I still find it confusing to have this sentence on the `label`:
>> 
>>>
>>> As a result, compared to {@link #id}, this label does not give a total order among instances.
>> 
>> To me, this feels odd because `label` being a `String` typically wouldn't have been considered to be playing a role in ordering. Plus, in isolation, it's not clear what ordering this talks about (Daniel did explain to me that the `id` field is used in ordering of open connections. I haven't yet looked deeper at that code to see where that happens).
>> 
>> In any case, this is an internal class so if we do decide to use the current proposed text, that's OK with me.
>
> I agree with Jaikiran: I would just remove the last sentence in this pargraph.

Implemented in 42ff0fc4a83cd33f1a35e4a2b3e7ce5c25ea39cc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028747158

From vyazici at openjdk.org  Fri Apr  4 12:47:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 4 Apr 2025 12:47:20 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v5]
In-Reply-To: <85yHuJ0fSjBVwvPmVyacNvYTLRa-bsADIuaawD4Vj5k=.cdb5ec21-1954-40c3-a7cc-433c132ee746@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <v-qBtMQK6kGwWt4Q83vXpCMDBgajQYp2bu2xJMa5_Xw=.c3b56ef5-80ca-4752-a799-98f9f9207fe6@github.com>
 <85yHuJ0fSjBVwvPmVyacNvYTLRa-bsADIuaawD4Vj5k=.cdb5ec21-1954-40c3-a7cc-433c132ee746@github.com>
Message-ID: <vYm04Mp5NRVpsUitk7CwEFYEXamPqU_LHBgky2vbcX8=.8097ec78-4a1c-43fa-b1e3-8586e61d8674@github.com>

On Wed, 2 Apr 2025 11:08:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review suggestions
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java line 114:
> 
>> 112: 
>> 113:     private static String nextLabel() {
>> 114:         return "" + LABEL_COUNTER.getAndIncrement();
> 
> The first label that this will generate will be `0`. It might be OK, but I think it would be better if we start it as `1`. So maybe consider using `LABEL_COUNTER.incrementAndGet()` instead?

Implemented in d64a901cf508ed7feeb0290733c61628d2ef9837.

> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 68:
> 
>> 66: import static org.junit.jupiter.api.Assertions.assertTrue;
>> 67: 
>> 68: @SuppressWarnings("OptionalGetWithoutIsPresent")
> 
> I haven't seen this `OptionalGetWithoutIsPresent` warning before and looking into the JDK repo I don't see it being used or recognized any place else. Is this meant for some specific IDEs?

Removed in bcf106b27063e886167a29ecc92a3073a4334c55.

> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 83:
> 
>> 81: 
>> 82:     // Start with a fresh client having no connections in the pool
>> 83:     @AutoClose
> 
> I hadn't come across this JUnit Jupiter annotation before. Reading through https://junit.org/junit5/docs/current/user-guide/#writing-tests-built-in-extensions-AutoClose it appears to be a convenience mechanism for managing closing of the resources at the "right time". That doc states:
> 
>> Specifically, if the test class is configured with @TestInstance(Lifecycle.PER_METHOD) semantics, a non-static @AutoClose field will be closed after the execution of each test method, test factory method, or test template method. However, if the test class is configured with @TestInstance(Lifecycle.PER_CLASS) semantics, a non-static @AutoClose field will not be closed until the current test class instance is no longer needed
> 
> Do you know what test class lifecycle is configured for test classes like this one when launched through jtreg?
> 
> Typically, we just use very basic JUnit constructs in the tests in the JDK repo to make it simpler to follow these tests, even if it means a bit more verbose code like having a method annotated with `@BeforeEach`/`@AfterEach` to do construction/clean up like this.

Replaced with `@AfterEach` in e32a48409478764ff5ab921c61be49f8ecffcff6.

> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 156:
> 
>> 154:                                         "Server[%s] is waiting for the latch... (connectionKey=%s, responseBody=%s)",
>> 155:                                         serverId, connectionKey, responseBody);
>> 156:                                 assertTrue(serverResponseLatchRef[0].await(2, TimeUnit.SECONDS));
> 
> We should avoid using any kind of timeouts here and in other places where we call this `await(...)` in this test. Given how varied the test execution environments are and our past experience with such timeouts, there's no right timeout to choose from. Instead, we should just do a `await()` without the timeout, so that if for whatever reason the latch isn't counted down, then the jtreg test execution timeout (which is controlled and configured externally to the test) will kick in and jtreg will do the necessary work of failing the test and also gathering detailed diagnostics through any failure handlers that are configured in that test execution environment.

Removed timeouts in 5b418fd7a9f4cfc3da940611ae3ba9d43e57aa91.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028746855
PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028746699
PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028746544
PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028746361

From dfuchs at openjdk.org  Fri Apr  4 12:56:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 12:56:03 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <qv7HjlgLp6J5BsLK4K6AouDLE6uQWG5D1fm9xBLS_PY=.9a8d47a7-1e1e-4264-bac3-12bb66b2d13c@github.com>

On Fri, 4 Apr 2025 12:37:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Looks reasonable to me. Changes to LoggingPermission look good. Out of curiosity I also  looked at all usages of RuntimePermission in the JDK - I believe you caught them all - including the unexpected use in XSLT.

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

PR Comment: https://git.openjdk.org/jdk/pull/24444#issuecomment-2778654645

From dfuchs at openjdk.org  Fri Apr  4 12:58:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 12:58:06 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
Message-ID: <amZQuWLOhR6qeL9oRaTlmMTRqSc2dWhLYDq-m0Eyfkg=.ac98ec6a-7d92-44e9-a6dc-caab2f5e4b1b@github.com>

On Fri, 4 Apr 2025 12:47:19 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Remove timeout from `CountDownLatch::await` calls
>  - Replace `@AutoClose` with a corresponding `@AfterEach` method
>  - Remove IDE-specific `OptionalGetWithoutIsPresent` warning suppression
>  - Improve `HttpConnection::label` JavaDoc
>  - Start from 1 while labeling connections

New changes look good to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24154#pullrequestreview-2742914834

From mullan at openjdk.org  Fri Apr  4 13:12:50 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 13:12:50 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
Message-ID: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>

Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.

The current API note in these classes was reused as the deprecation text. 

Release Note: https://bugs.openjdk.org/browse/JDK-8353680

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

Commit messages:
 - Remove trailing whitespace.
 - Initial revision.

Changes: https://git.openjdk.org/jdk/pull/24445/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348967
  Stats: 53 lines in 15 files changed: 34 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24445/head:pull/24445

PR: https://git.openjdk.org/jdk/pull/24445

From vyazici at openjdk.org  Fri Apr  4 13:13:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 4 Apr 2025 13:13:58 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v4]
In-Reply-To: <aeDyI4A1iU1EiSlcJMtrgubaUvITBvju5gcUE9sAi7c=.b7810218-94df-4a8e-976b-9912832cd94a@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <tAIXaR9JwJp5BPPLXFmao8eS-gRZj_Wm7c9v369IZ5I=.515939fe-d758-4188-838e-554817c12a10@github.com>
 <qjgXuVsn4GgXWo7GHg0u2blkrfT_h6r0wsn1Pt7oQZc=.012b7da6-a1ed-4d86-81ee-fc58e698a42f@github.com>
 <aeDyI4A1iU1EiSlcJMtrgubaUvITBvju5gcUE9sAi7c=.b7810218-94df-4a8e-976b-9912832cd94a@github.com>
Message-ID: <qtk16ZOGajuWZNpHkB17AEZkwikT5aerOt-Lnif4DBo=.6fe74497-213c-465d-85e2-9e9d041c4db0@github.com>

On Tue, 1 Apr 2025 19:18:18 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java line 81:
>> 
>>> 79:             = Comparator.comparing(HttpConnection::id);
>>> 80: 
>>> 81:     private static final AtomicLong LABEL_COUNTER = new AtomicLong();
>> 
>> In the API documentation on `HttpResponse.connectionLabel()` we talk about the connection label being unique within a `HttpClient` scope. i.e. two different `HttpClient` instances could have the same connectionLabel for a connection. I think that's the right scoping.
>> 
>> So given that, having a `static` field on a `HttpConnection` which keeps track of a connection label, may not be the right place to keep track of that state. In this proposed form, no two connections in two different HttpClient instances will ever have the same connectionLabel. I think this counter should probably be present on the `HttpClientImpl` as an instance field.
>
> @jaikiran, what you're suggesting makes sense. I'm still exploring the interplay between the connection label and HTTP/3 server pushes. I will return back to your suggestion soon.

> In this proposed form, no two connections in two different HttpClient instances will ever have the same `connectionLabel`.

Yes, but this is neither required by the connection label contract. That is, the contract doesn't say that they must have overlapping connection labels. It only states connection labels are unique-per-client. Our implementation is more stricter than that: unique-per-VM, but that is just an implementation detail.

> I think this counter should probably be present on the `HttpClientImpl` as an instance field.

I've given this approach an attempt. Though I find it difficult to reason about in the code that a counter _only_ `HttpConnection` uses is situated in `HttpClientImpl`, just to make two `HttpConnection`s from different `HttpClientImpl`s share the connection label.

I also agree with @dfuch that having a unique-per-VM connection label helps with troubleshooting too.

@jaikiran, unless you're strongly opinionated about this, I prefer to leave the connection label counter in `HttpConnection`. How shall we proceed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028788343

From duke at openjdk.org  Fri Apr  4 13:53:57 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 4 Apr 2025 13:53:57 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
Message-ID: <mqmRUpua_VVLtbTP8qGz6olmHvjxqIcctmhq96L73Yg=.1e6a522c-4ef7-426c-9a85-74f460793978@github.com>

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.

I agree with most of these, however the permissions infrastructure *itself* is still used for user-level authorization (at least in WildFly/JBoss middleware, and I would assume other places as well). Part of this infrastructure does rely on `AllPermission` and its `PermissionCollection`. I don't see a reason to deprecate `AllPermission` before deprecating `Permission` itself.

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

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778791218

From mullan at openjdk.org  Fri Apr  4 14:15:48 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 14:15:48 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
Message-ID: <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

> > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> I agree with most of these, however the permissions infrastructure _itself_ is still used for user-level authorization (at least in WildFly/JBoss middleware, and I would assume other places as well). Part of this infrastructure does rely on `AllPermission` and its `PermissionCollection`. I don't see a reason to deprecate `AllPermission` before deprecating `Permission` itself.

Can you elaborate or give an example/pointer to code on how it uses `AllPermission` w/o the corresponding SM APIs and infrastructure (policy files, `AccessController`, etc)?

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

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778846121

From jpai at openjdk.org  Fri Apr  4 14:51:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Apr 2025 14:51:08 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
Message-ID: <HZKiSGfhXPHvz-qEJGNON99MfIdLbIGUd0qzcuJwuo0=.59c7f542-b0d6-4ea2-b079-681faef069d4@github.com>

On Fri, 4 Apr 2025 12:47:19 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Remove timeout from `CountDownLatch::await` calls
>  - Replace `@AutoClose` with a corresponding `@AfterEach` method
>  - Remove IDE-specific `OptionalGetWithoutIsPresent` warning suppression
>  - Improve `HttpConnection::label` JavaDoc
>  - Start from 1 while labeling connections

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 190:

> 188:         private static HttpTestServer createServer(Version version, SSLContext sslContext) {
> 189:             try {
> 190:                 return HttpTestServer.create(version, sslContext, ForkJoinPool.commonPool());

The HTTP/2 test server in the JDK shuts down the `Executor` that is passed to that server (like this one), when the server is stopped. I had a look at the specification and implementation of `ForkJoinPool.commonPool()` - it is specified to not close/shutdown the common pool. So I think it is OK to use the `commonPool()` as the `Executor` for these servers.

Although, since this test is agentvm test, we never known what state the commonPool() executor is in due to some previously run test(s). Maybe we should consider having a test specific Executor in this test, like we do in some other tests within the httpclient tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028968733

From duke at openjdk.org  Fri Apr  4 14:51:58 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 4 Apr 2025 14:51:58 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
 <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>
Message-ID: <vvXq4tdKDAmBjg_kuXghR77OjdT5c5mPfjHCijhbgh8=.e05548f1-aec5-4e25-a5b9-80d0eb70c9c1@github.com>

On Fri, 4 Apr 2025 14:12:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> > 
> > 
> > I agree with most of these, however the permissions infrastructure _itself_ is still used for user-level authorization (at least in WildFly/JBoss middleware, and I would assume other places as well). Part of this infrastructure does rely on `AllPermission` and its `PermissionCollection`. I don't see a reason to deprecate `AllPermission` before deprecating `Permission` itself.
> 
> Can you elaborate or give an example/pointer to code on how it uses `AllPermission` w/o the corresponding SM APIs and infrastructure (policy files, `AccessController`, etc)?

The [`wildfly-elytron`](https://github.com/wildfly-security/wildfly-elytron) project uses `Permission` and `PermissionCollection` as a standalone basic API to represent user authorization permissions. Some examples include `LoginPermission` and `RunAsPrincipalPermission`, and a special `NoPermission` class which is useful in certain situations.

The user authorization mechanism does not use policy files, security manager APIs, `AccessController` or any other JAAS-adjacent API for this purpose.

Security contexts are managed completely separately from the JDK using thread local scoping (planned to move to `ScopedValue` someday if/when it becomes available). Permissions are checked against the user security context (`org.wildfly.security.auth.server.SecurityIdentity`) by authorization-sensitive operations in both server and user code.

The `AllPermission` class is used for "superuser" authorization situations, and cases where the deployer opts out of authorization checks for whatever reason (for example, testing). We use it for role-based access control of the application server itself when access control checks pass, as well for superuser authorization cases, and probably other cases I'm forgetting about (it's one of those things that we always assumed would stick around forever, so we used it without a second thought).

`AllPermission` is an integral concept of permission sets, and thus we would be obliged to create our own if the JDK one disappeared, causing compatibility problems due to the class moving to a new package from the point of view of consumers. Its destiny should be tied to that of `Permission` itself in my opinion, because it is pretty fundamental.

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

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492

From dfuchs at openjdk.org  Fri Apr  4 14:58:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 14:58:14 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <HZKiSGfhXPHvz-qEJGNON99MfIdLbIGUd0qzcuJwuo0=.59c7f542-b0d6-4ea2-b079-681faef069d4@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
 <HZKiSGfhXPHvz-qEJGNON99MfIdLbIGUd0qzcuJwuo0=.59c7f542-b0d6-4ea2-b079-681faef069d4@github.com>
Message-ID: <v694_bZNDg5zFXyub8oyM3fTwqMOC7D6x93TS3jpQiY=.1601608a-d7b0-48ce-8f0a-36dbec3328db@github.com>

On Fri, 4 Apr 2025 14:48:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Remove timeout from `CountDownLatch::await` calls
>>  - Replace `@AutoClose` with a corresponding `@AfterEach` method
>>  - Remove IDE-specific `OptionalGetWithoutIsPresent` warning suppression
>>  - Improve `HttpConnection::label` JavaDoc
>>  - Start from 1 while labeling connections
>
> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 190:
> 
>> 188:         private static HttpTestServer createServer(Version version, SSLContext sslContext) {
>> 189:             try {
>> 190:                 return HttpTestServer.create(version, sslContext, ForkJoinPool.commonPool());
> 
> The HTTP/2 test server in the JDK shuts down the `Executor` that is passed to that server (like this one), when the server is stopped. I had a look at the specification and implementation of `ForkJoinPool.commonPool()` - it is specified to not close/shutdown the common pool. So I think it is OK to use the `commonPool()` as the `Executor` for these servers.
> 
> Although, since this test is agentvm test, we never known what state the commonPool() executor is in due to some previously run test(s). Maybe we should consider having a test specific Executor in this test, like we do in some other tests within the httpclient tests.

Another possibility is to run in /othervm mode - then we don't care...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028979965

From duke at openjdk.org  Fri Apr  4 15:02:23 2025
From: duke at openjdk.org (robert engels)
Date: Fri, 4 Apr 2025 15:02:23 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
Message-ID: <uqUlOGhbWCYINtsnwNBfHm6-ChZHy6Kj6BVU57Tg72s=.4b131667-dc77-46b3-bbd7-d1265a17dff0@github.com>

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

Sad day when the Java backwards compatibility promise is thrown out the window because a bunch of developers need work to do. Removing these classes does nothing towards the reduced api surface the goal of removing the SM had. I suspect these classes haven?t changed in 20 years.

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

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778984443

From daniel.fuchs at oracle.com  Fri Apr  4 15:04:19 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 4 Apr 2025 16:04:19 +0100
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: <vvXq4tdKDAmBjg_kuXghR77OjdT5c5mPfjHCijhbgh8=.e05548f1-aec5-4e25-a5b9-80d0eb70c9c1@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
 <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>
 <vvXq4tdKDAmBjg_kuXghR77OjdT5c5mPfjHCijhbgh8=.e05548f1-aec5-4e25-a5b9-80d0eb70c9c1@github.com>
Message-ID: <d009b84c-f59c-4c8b-b440-6a60d6aa4332@oracle.com>

Hi David,

Are there other subclasses of Permission that this framework uses?
More specifically - would it be fine to deprecate NetPermission,
URLPermission and SocketPermission classes?

best regards,

-- daniel

On 04/04/2025 15:51, David M. Lloyd wrote:
>> Can you elaborate or give an example/pointer to code on how it uses `AllPermission` w/o the corresponding SM APIs and infrastructure (policy files, `AccessController`, etc)?
> 
> The [`wildfly-elytron`](https://github.com/wildfly-security/wildfly-elytron) project uses `Permission` and `PermissionCollection` as a standalone basic API to represent user authorization permissions. Some examples include `LoginPermission` and `RunAsPrincipalPermission`, and a special `NoPermission` class which is useful in certain situations.
> 
> The user authorization mechanism does not use policy files, security manager APIs, `AccessController` or any other JAAS-adjacent API for this purpose.
> 
> Security contexts are managed completely separately from the JDK using thread local scoping (planned to move to `ScopedValue` someday if/when it becomes available). Permissions are checked against the user security context (`org.wildfly.security.auth.server.SecurityIdentity`) by authorization-sensitive operations in both server and user code.
> 
> The `AllPermission` class is used for "superuser" authorization situations, and cases where the deployer opts out of authorization checks for whatever reason (for example, testing). We use it for role-based access control of the application server itself when access control checks pass, as well for superuser authorization cases, and probably other cases I'm forgetting about (it's one of those things that we always assumed would stick around forever, so we used it without a second thought).
> 
> `AllPermission` is an integral concept of permission sets, and thus we would be obliged to create our own if the JDK one disappeared, causing compatibility problems due to the class moving to a new package from the point of view of consumers. Its destiny should be tied to that of `Permission` itself in my opinion, because it is pretty fundamental.
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492


From jpai at openjdk.org  Fri Apr  4 15:05:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Apr 2025 15:05:53 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
Message-ID: <ij0giTwjyvA3qsia7jpmUoWHNVWcvQU3UrXaLMt1qpg=.453edc53-1a8b-45c2-95a6-d8b658828417@github.com>

On Fri, 4 Apr 2025 12:47:19 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Remove timeout from `CountDownLatch::await` calls
>  - Replace `@AutoClose` with a corresponding `@AfterEach` method
>  - Remove IDE-specific `OptionalGetWithoutIsPresent` warning suppression
>  - Improve `HttpConnection::label` JavaDoc
>  - Start from 1 while labeling connections

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 168:

> 166: 
> 167:                         } catch (IOException ioe) {
> 168:                             synchronized (ServerRequestPair.class) {

Is the synchronization intentional here?

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 173:

> 171:                                         serverId, connectionKey, responseBody);
> 172:                                 ioe.printStackTrace(System.out);
> 173:                             }

Shouldn't we be rethrowing these exceptions from the handler to fail the request?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028990169
PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028991004

From jpai at openjdk.org  Fri Apr  4 15:05:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Apr 2025 15:05:54 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <v694_bZNDg5zFXyub8oyM3fTwqMOC7D6x93TS3jpQiY=.1601608a-d7b0-48ce-8f0a-36dbec3328db@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
 <HZKiSGfhXPHvz-qEJGNON99MfIdLbIGUd0qzcuJwuo0=.59c7f542-b0d6-4ea2-b079-681faef069d4@github.com>
 <v694_bZNDg5zFXyub8oyM3fTwqMOC7D6x93TS3jpQiY=.1601608a-d7b0-48ce-8f0a-36dbec3328db@github.com>
Message-ID: <h96xV24EilB9VUl7TD2WoLQSPPCiGTRZhq9I7sVmvYk=.9684910e-2c81-43bd-a212-f79644bc34d7@github.com>

On Fri, 4 Apr 2025 14:55:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 190:
>> 
>>> 188:         private static HttpTestServer createServer(Version version, SSLContext sslContext) {
>>> 189:             try {
>>> 190:                 return HttpTestServer.create(version, sslContext, ForkJoinPool.commonPool());
>> 
>> The HTTP/2 test server in the JDK shuts down the `Executor` that is passed to that server (like this one), when the server is stopped. I had a look at the specification and implementation of `ForkJoinPool.commonPool()` - it is specified to not close/shutdown the common pool. So I think it is OK to use the `commonPool()` as the `Executor` for these servers.
>> 
>> Although, since this test is agentvm test, we never known what state the commonPool() executor is in due to some previously run test(s). Maybe we should consider having a test specific Executor in this test, like we do in some other tests within the httpclient tests.
>
> Another possibility is to run in /othervm mode - then we don't care...

Yes, I think othervm would be fine. In fact, I was adding a review comment in another context, where I suspect we might be forced to use the othervm mode anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028992574

From jpai at openjdk.org  Fri Apr  4 15:12:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Apr 2025 15:12:52 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
Message-ID: <L2BPpb9NOPBaAwnKL8GFsXwnN3gYwMPKOt13WqeRy9A=.116b721c-1e2c-415f-a821-99736848eb41@github.com>

On Fri, 4 Apr 2025 12:47:19 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Remove timeout from `CountDownLatch::await` calls
>  - Replace `@AutoClose` with a corresponding `@AfterEach` method
>  - Remove IDE-specific `OptionalGetWithoutIsPresent` warning suppression
>  - Improve `HttpConnection::label` JavaDoc
>  - Start from 1 while labeling connections

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 412:

> 410:         HttpResponse<String> response1 = client.send(pair.request, BodyHandlers.ofString(CHARSET));
> 411:         LOGGER.log("Firing request 2...");
> 412:         HttpResponse<String> response2 = client.send(pair.request, BodyHandlers.ofString(CHARSET));

In theory, there's no guarantee that these sequential requests will be executed "immediately" one after the other. Internally, in the httpclient implementation, we use idle timeouts to close idle connections. So I'm wondering if it's realistic that there would ever be a case where in some setup (like the CI), these two execute so far apart from each other (`-Xcomp`?) that the connection might have timed out in the meantime and closed? Thus the second request ends up using a different connection and fails this test?
Should we perhaps use `othervm` for this test and configure an extremely high idle timeout of connections, through the system properties, to avoid such intermittent failures?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2028999507

From david.lloyd at redhat.com  Fri Apr  4 15:22:48 2025
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 4 Apr 2025 10:22:48 -0500
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: <d009b84c-f59c-4c8b-b440-6a60d6aa4332@oracle.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
 <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>
 <vvXq4tdKDAmBjg_kuXghR77OjdT5c5mPfjHCijhbgh8=.e05548f1-aec5-4e25-a5b9-80d0eb70c9c1@github.com>
 <d009b84c-f59c-4c8b-b440-6a60d6aa4332@oracle.com>
Message-ID: <CANghgrTWAvT+-Npp-a8kkdSD0hq_TneoGpA7s50GaJz73KPfVw@mail.gmail.com>

Greetings Daniel,

For the sake of discussion, I will look at these classes as classifiable
into two groups: classes that we use (or are useful) only in the context of
a security manager, and classes that we use (or are useful) independently
of any other JDK API.

I would put all three of these classes (`NetPermission`, `URLPermission`,
and `SocketPermission`) in the former category, as well as the other
non-`AllPermission` classes listed in Sean's PR: we (and our users) would
use them only in the context of a security manager, so when that is gone,
our need to support these classes goes with it, as far as I can tell.

The classes that we would continue to require on an ongoing basis (to my
knowledge) would include `Permission` itself (obviously), `AllPermission`,
and the `BasicPermission` base class (which also seems to be subclassed by
many third-party projects).

On Fri, Apr 4, 2025 at 10:05?AM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi David,
>
> Are there other subclasses of Permission that this framework uses?
> More specifically - would it be fine to deprecate NetPermission,
> URLPermission and SocketPermission classes?
>
> best regards,
>
> -- daniel
>
> On 04/04/2025 15:51, David M. Lloyd wrote:
> >> Can you elaborate or give an example/pointer to code on how it uses
> `AllPermission` w/o the corresponding SM APIs and infrastructure (policy
> files, `AccessController`, etc)?
> >
> > The [`wildfly-elytron`](
> https://github.com/wildfly-security/wildfly-elytron) project uses
> `Permission` and `PermissionCollection` as a standalone basic API to
> represent user authorization permissions. Some examples include
> `LoginPermission` and `RunAsPrincipalPermission`, and a special
> `NoPermission` class which is useful in certain situations.
> >
> > The user authorization mechanism does not use policy files, security
> manager APIs, `AccessController` or any other JAAS-adjacent API for this
> purpose.
> >
> > Security contexts are managed completely separately from the JDK using
> thread local scoping (planned to move to `ScopedValue` someday if/when it
> becomes available). Permissions are checked against the user security
> context (`org.wildfly.security.auth.server.SecurityIdentity`) by
> authorization-sensitive operations in both server and user code.
> >
> > The `AllPermission` class is used for "superuser" authorization
> situations, and cases where the deployer opts out of authorization checks
> for whatever reason (for example, testing). We use it for role-based access
> control of the application server itself when access control checks pass,
> as well for superuser authorization cases, and probably other cases I'm
> forgetting about (it's one of those things that we always assumed would
> stick around forever, so we used it without a second thought).
> >
> > `AllPermission` is an integral concept of permission sets, and thus we
> would be obliged to create our own if the JDK one disappeared, causing
> compatibility problems due to the class moving to a new package from the
> point of view of consumers. Its destiny should be tied to that of
> `Permission` itself in my opinion, because it is pretty fundamental.
> >
> > -------------
> >
> > PR Comment:
> https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492
>
>

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250404/dde623cd/attachment-0001.htm>

From dfuchs at openjdk.org  Fri Apr  4 15:30:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 15:30:58 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <L2BPpb9NOPBaAwnKL8GFsXwnN3gYwMPKOt13WqeRy9A=.116b721c-1e2c-415f-a821-99736848eb41@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
 <L2BPpb9NOPBaAwnKL8GFsXwnN3gYwMPKOt13WqeRy9A=.116b721c-1e2c-415f-a821-99736848eb41@github.com>
Message-ID: <CubYJxZgrURSsvD5yrT4Tu8aebziaRab9HIypzG5lbE=.e28a031d-ec53-48c2-a9dd-7f4e27d5aa10@github.com>

On Fri, 4 Apr 2025 15:08:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Remove timeout from `CountDownLatch::await` calls
>>  - Replace `@AutoClose` with a corresponding `@AfterEach` method
>>  - Remove IDE-specific `OptionalGetWithoutIsPresent` warning suppression
>>  - Improve `HttpConnection::label` JavaDoc
>>  - Start from 1 while labeling connections
>
> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 412:
> 
>> 410:         HttpResponse<String> response1 = client.send(pair.request, BodyHandlers.ofString(CHARSET));
>> 411:         LOGGER.log("Firing request 2...");
>> 412:         HttpResponse<String> response2 = client.send(pair.request, BodyHandlers.ofString(CHARSET));
> 
> In theory, there's no guarantee that these sequential requests will be executed "immediately" one after the other. Internally, in the httpclient implementation, we use idle timeouts to close idle connections. So I'm wondering if it's realistic that there would ever be a case where in some setup (like the CI), these two execute so far apart from each other (`-Xcomp`?) that the connection might have timed out in the meantime and closed? Thus the second request ends up using a different connection and fails this test?
> Should we perhaps use `othervm` for this test and configure an extremely high idle timeout of connections, through the system properties, to avoid such intermittent failures?

Good point - our default idle timeout is 30s IIRC. There would need to be a pause of 30s between the two calls to `client.send` however. Not impossible but unlikely. We could either pass a higher timeout (with e.g. `-Djdk.httpclient.keepalive.timeout=120`) preemptively, or wait until we see the test fail...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2029032560

From dfuchs at openjdk.org  Fri Apr  4 15:38:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 15:38:50 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
Message-ID: <-lk13iK-xcpj57om_W2geIwkx_35JQSE9sKcMzEaMec=.7b41608b-e63d-47ab-aee6-ecdafc2f635f@github.com>

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

Thanks David!

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

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2779110623

From mullan at openjdk.org  Fri Apr  4 16:22:47 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 16:22:47 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: <vvXq4tdKDAmBjg_kuXghR77OjdT5c5mPfjHCijhbgh8=.e05548f1-aec5-4e25-a5b9-80d0eb70c9c1@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
 <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com>
 <vvXq4tdKDAmBjg_kuXghR77OjdT5c5mPfjHCijhbgh8=.e05548f1-aec5-4e25-a5b9-80d0eb70c9c1@github.com>
Message-ID: <X9K8E03iVKo_Gzrr0U1BH24C7WZywGP_sfM_DyVqeW4=.66e83a6f-12ed-4dab-99af-32072ec55646@github.com>

On Fri, 4 Apr 2025 14:49:36 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> `AllPermission` is an integral concept of permission sets, and thus we would be obliged to create our own if the JDK one disappeared, causing compatibility problems due to the class moving to a new package from the point of view of consumers. Its destiny should be tied to that of `Permission` itself in my opinion, because it is pretty fundamental.

Yes, I can see now that this permission is different than the other JDK specific permissions that are being deprecated for removal. I will leave it as-is for now, undeprecated.

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

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2779219067

From duke at openjdk.org  Fri Apr  4 16:25:53 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 4 Apr 2025 16:25:53 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
In-Reply-To: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
Message-ID: <XPMKyYilvppzBCAorbpWqWdMGC59_qB4JowE18DrvMs=.79953c3a-03e5-4ed9-b165-83ccb91c550b@github.com>

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

Great, thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2779226283

From jpai at openjdk.org  Fri Apr  4 16:38:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Apr 2025 16:38:51 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <CubYJxZgrURSsvD5yrT4Tu8aebziaRab9HIypzG5lbE=.e28a031d-ec53-48c2-a9dd-7f4e27d5aa10@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
 <L2BPpb9NOPBaAwnKL8GFsXwnN3gYwMPKOt13WqeRy9A=.116b721c-1e2c-415f-a821-99736848eb41@github.com>
 <CubYJxZgrURSsvD5yrT4Tu8aebziaRab9HIypzG5lbE=.e28a031d-ec53-48c2-a9dd-7f4e27d5aa10@github.com>
Message-ID: <a1xNzGbe34yEzRpxDoMTbg9dFqkXtGes9pCFsyycZW4=.1012e19e-9a3a-4ddd-9d98-0cb24783331d@github.com>

On Fri, 4 Apr 2025 15:27:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 412:
>> 
>>> 410:         HttpResponse<String> response1 = client.send(pair.request, BodyHandlers.ofString(CHARSET));
>>> 411:         LOGGER.log("Firing request 2...");
>>> 412:         HttpResponse<String> response2 = client.send(pair.request, BodyHandlers.ofString(CHARSET));
>> 
>> In theory, there's no guarantee that these sequential requests will be executed "immediately" one after the other. Internally, in the httpclient implementation, we use idle timeouts to close idle connections. So I'm wondering if it's realistic that there would ever be a case where in some setup (like the CI), these two execute so far apart from each other (`-Xcomp`?) that the connection might have timed out in the meantime and closed? Thus the second request ends up using a different connection and fails this test?
>> Should we perhaps use `othervm` for this test and configure an extremely high idle timeout of connections, through the system properties, to avoid such intermittent failures?
>
> Good point - our default idle timeout is 30s IIRC. There would need to be a pause of 30s between the two calls to `client.send` however. Not impossible but unlikely. We could either pass a higher timeout (with e.g. `-Djdk.httpclient.keepalive.timeout=120`) preemptively, or wait until we see the test fail...

Waiting for the test to fail due to this reason and then adjusting the timeout is fine with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2029126877

From rriggs at openjdk.org  Fri Apr  4 16:39:27 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 16:39:27 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v2]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <-VbTKqOznNLKI7R7AHZEECmO_Gfu5aYoFpE7T2FriqY=.79b97a1a-1787-465c-b6a8-f590a01c8f9b@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Add SuppressWarnings to a Windows source missed earlier.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/3ae4467e..1fa560a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From dfuchs at openjdk.org  Fri Apr  4 16:43:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 16:43:50 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <a1xNzGbe34yEzRpxDoMTbg9dFqkXtGes9pCFsyycZW4=.1012e19e-9a3a-4ddd-9d98-0cb24783331d@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
 <L2BPpb9NOPBaAwnKL8GFsXwnN3gYwMPKOt13WqeRy9A=.116b721c-1e2c-415f-a821-99736848eb41@github.com>
 <CubYJxZgrURSsvD5yrT4Tu8aebziaRab9HIypzG5lbE=.e28a031d-ec53-48c2-a9dd-7f4e27d5aa10@github.com>
 <a1xNzGbe34yEzRpxDoMTbg9dFqkXtGes9pCFsyycZW4=.1012e19e-9a3a-4ddd-9d98-0cb24783331d@github.com>
Message-ID: <AITGCXp_eE4WSflAAuxiqcyrySODzTU_d3FfYbQhv08=.88425889-5499-4d7c-8259-80871596be25@github.com>

On Fri, 4 Apr 2025 16:36:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Good point - our default idle timeout is 30s IIRC. There would need to be a pause of 30s between the two calls to `client.send` however. Not impossible but unlikely. We could either pass a higher timeout (with e.g. `-Djdk.httpclient.keepalive.timeout=120`) preemptively, or wait until we see the test fail...
>
> Waiting for the test to fail due to this reason and then adjusting the timeout is fine with me.

On the plus side - if we add the `-Djdk.httpclient.keepalive.timeout=120` now we might not have to deal with it later, and maybe it will give us a clue if the test ever fails due to this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2029133030

From mullan at openjdk.org  Fri Apr  4 18:04:39 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 18:04:39 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v2]
In-Reply-To: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
Message-ID: <E9pqBMlMGsu7IMQJTtlXU-MaDz7vm_wV6quoIHPswj0=.06274c73-9481-46d6-b309-927fa49c50fc@github.com>

> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

Sean Mullan has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'JDK-8348967' of gh:seanjmullan/jdk into JDK-8348967
 - Revert "Initial revision."
   Undeprecate AllPermission.
   
   This reverts commit 38938d9d56672ecc374c3d86a891c95e6b164d02.
 - Remove trailing whitespace.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24445/files
  - new: https://git.openjdk.org/jdk/pull/24445/files/de5f360e..8dae2f8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=00-01

  Stats: 19 lines in 8 files changed: 0 ins; 15 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24445/head:pull/24445

PR: https://git.openjdk.org/jdk/pull/24445

From rriggs at openjdk.org  Fri Apr  4 18:21:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 18:21:29 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v3]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <WFSjet0Va39HuO_4pcHMq0VS6fn504v_fAoCE72_TRg=.e4cf6bad-fd3b-4e5c-a478-9192054bb168@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Updated style of @Deprecated to match most existing @Deprecated annotations
  `since` comes before `forRemoval`
  No spaces around `=`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/1fa560a4..bb18c1e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=01-02

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From rriggs at openjdk.org  Fri Apr  4 18:26:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 18:26:50 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v2]
In-Reply-To: <E9pqBMlMGsu7IMQJTtlXU-MaDz7vm_wV6quoIHPswj0=.06274c73-9481-46d6-b309-927fa49c50fc@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
 <E9pqBMlMGsu7IMQJTtlXU-MaDz7vm_wV6quoIHPswj0=.06274c73-9481-46d6-b309-927fa49c50fc@github.com>
Message-ID: <4U4fHTMkZq09NuiU-svQOicKoYLqEMUmIyUcNZnTNgw=.09aa34d1-23a7-4c76-8050-727875c54ffe@github.com>

On Fri, 4 Apr 2025 18:04:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
>> 
>> The current API note in these classes was reused as the deprecation text. 
>> 
>> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
>
> Sean Mullan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge branch 'JDK-8348967' of gh:seanjmullan/jdk into JDK-8348967
>  - Revert "Initial revision."
>    Undeprecate AllPermission.
>    
>    This reverts commit 38938d9d56672ecc374c3d86a891c95e6b164d02.
>  - Remove trailing whitespace.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2743809469

From iris at openjdk.org  Fri Apr  4 18:33:58 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 4 Apr 2025 18:33:58 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v2]
In-Reply-To: <E9pqBMlMGsu7IMQJTtlXU-MaDz7vm_wV6quoIHPswj0=.06274c73-9481-46d6-b309-927fa49c50fc@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
 <E9pqBMlMGsu7IMQJTtlXU-MaDz7vm_wV6quoIHPswj0=.06274c73-9481-46d6-b309-927fa49c50fc@github.com>
Message-ID: <5KYDV4UYQqtRvB8n6oeHBpCV5MhrsKSQWsAjC_Rotg8=.28c75b48-6362-4970-96f8-b9f104e25d2a@github.com>

On Fri, 4 Apr 2025 18:04:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
>> 
>> The current API note in these classes was reused as the deprecation text. 
>> 
>> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
>
> Sean Mullan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge branch 'JDK-8348967' of gh:seanjmullan/jdk into JDK-8348967
>  - Revert "Initial revision."
>    Undeprecate AllPermission.
>    
>    This reverts commit 38938d9d56672ecc374c3d86a891c95e6b164d02.
>  - Remove trailing whitespace.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2743822700

From iris at openjdk.org  Fri Apr  4 18:40:50 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 4 Apr 2025 18:40:50 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v3]
In-Reply-To: <WFSjet0Va39HuO_4pcHMq0VS6fn504v_fAoCE72_TRg=.e4cf6bad-fd3b-4e5c-a478-9192054bb168@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <WFSjet0Va39HuO_4pcHMq0VS6fn504v_fAoCE72_TRg=.e4cf6bad-fd3b-4e5c-a478-9192054bb168@github.com>
Message-ID: <9XnN5LLqYWAbbv3Smz9WTvMTZcbGwpGnQJtozSQm0Co=.ba9516ba-7fdc-4694-88e4-93a78a788099@github.com>

On Fri, 4 Apr 2025 18:21:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated style of @Deprecated to match most existing @Deprecated annotations
>   `since` comes before `forRemoval`
>   No spaces around `=`

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24444#pullrequestreview-2743835110

From rriggs at openjdk.org  Fri Apr  4 19:00:02 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 19:00:02 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v4]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <dFrchMH6C9V8xZsDQJo0PDn7NcpYixHxfCMaLm7ZjwI=.f2defaf4-72dc-42db-989d-1b6e6aaa5d61@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused import of LinkPermission

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/bb18c1e6..25aa6099

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From mullan at openjdk.org  Fri Apr  4 19:07:59 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 19:07:59 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v4]
In-Reply-To: <dFrchMH6C9V8xZsDQJo0PDn7NcpYixHxfCMaLm7ZjwI=.f2defaf4-72dc-42db-989d-1b6e6aaa5d61@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <dFrchMH6C9V8xZsDQJo0PDn7NcpYixHxfCMaLm7ZjwI=.f2defaf4-72dc-42db-989d-1b6e6aaa5d61@github.com>
Message-ID: <ji0Vw4K2eD3TJSjHCWkv_goEcxz9MDwURNCM3yV2LWg=.26adbdbc-a7f5-43b0-838c-a7ed746c919e@github.com>

On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import of LinkPermission

Some copyright dates have not been updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/24444#issuecomment-2779539268

From rriggs at openjdk.org  Fri Apr  4 19:15:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 19:15:29 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v5]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <x63KCZyWbSe94q9z-eouE19aFtmSCBf_XgAWNA2tXXE=.43d9f241-be4d-44dc-a8d3-c0ad8f25a741@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright in WindowsFileCopy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/25aa6099..c1457493

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From mullan at openjdk.org  Fri Apr  4 19:15:29 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 19:15:29 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v4]
In-Reply-To: <dFrchMH6C9V8xZsDQJo0PDn7NcpYixHxfCMaLm7ZjwI=.f2defaf4-72dc-42db-989d-1b6e6aaa5d61@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <dFrchMH6C9V8xZsDQJo0PDn7NcpYixHxfCMaLm7ZjwI=.f2defaf4-72dc-42db-989d-1b6e6aaa5d61@github.com>
Message-ID: <lqupDkICj8xMqDWeqWRk4LXqu_ngGAW-PtSLpRAUkAc=.0bc4bc14-fc58-449e-a235-2f7721d2e82e@github.com>

On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import of LinkPermission

src/java.base/share/classes/java/io/FilePermission.java line 87:

> 85: 
> 86: @Deprecated(since="25", forRemoval=true)
> 87: @SuppressWarnings("removal")

Is this leftover? You already add it to the methods that need it.

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 202:

> 200:     }
> 201: 
> 202:     @SuppressWarnings("removal")

This should not be necessary.

src/java.logging/share/classes/java/util/logging/LoggingPermission.java line 48:

> 46:  */
> 47: 
> 48: @Deprecated(forRemoval = true, since="25")

This order is different than other classes, maybe make it consistent?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029312409
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029308725
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029311303

From rriggs at openjdk.org  Fri Apr  4 19:22:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 19:22:46 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v6]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <FpwQiXKgwZOWkkHnSYhVi35mOhTqSKlv0hfIny3kwuA=.2b7f303c-9619-4b4e-9f5d-1311317627c8@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary SuppressWarnings and correct Deprecated annotation style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/c1457493..9a9417a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=04-05

  Stats: 3 lines in 3 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From rriggs at openjdk.org  Fri Apr  4 19:24:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 19:24:52 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
Message-ID: <hNrUJ_FoiG0Qxz-xHKIJxwSN2-h5wIAXsThHnVs6y7I=.60e4b93e-aa69-44dc-ba20-6d6f878145d1@github.com>

On Sat, 29 Mar 2025 17:27:20 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24314#pullrequestreview-2743911875

From duke at openjdk.org  Fri Apr  4 20:42:50 2025
From: duke at openjdk.org (duke)
Date: Fri, 4 Apr 2025 20:42:50 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
Message-ID: <HzMWawP2B0uZiTalzY8F8zQhpeIQOz9hqklrl7DaPJo=.f580e034-d7af-4646-bba0-4ca533e614e3@github.com>

On Sat, 29 Mar 2025 17:27:20 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.

@kilink 
Your change (at version 64ddccdaeeaec4e1196976d3c5f4c329008dd4ef) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24314#issuecomment-2779690972

From eirbjo at openjdk.org  Sat Apr  5 11:08:31 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 5 Apr 2025 11:08:31 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
Message-ID: <2Npic-M0k5PeOIVi10Vswokk6naB8u0fN2GQQKe1bNE=.49d4f6bc-f218-4e90-a85e-a0744ca4701c@github.com>

Please help review this PR which improves `HttpServer::stop` termination timing to better fit user expectations.

This PR:

* Makes `ServerImpl::stop` continue without delay when there are no active exchanges during shutdown
* Attempts to interrupt the dispatcher thread before joining it, giving long-living interruptible exchanges a chance to finish  early
* Adds testing for boundary conditions with or without an active exchange, delay occurring before exhange completes and exchange completing before delay.

Additinally, `ServerImpl::stop` is updated to use `System::nanotime` instead of `System::currentTimeMillis` when calculating wait times.

The test relies on timing to assert the order of events. Not perfect, but it seems to work.

(This part of the code base is rather new to me. A bit of hand-holding should be expected when reviewing this PR)

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

Commit messages:
 - Improve shutdown sequence in HttpServerImpl::stop

Changes: https://git.openjdk.org/jdk/pull/24467/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24467&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304065
  Stats: 237 lines in 2 files changed: 231 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24467/head:pull/24467

PR: https://git.openjdk.org/jdk/pull/24467

From alanb at openjdk.org  Mon Apr  7 06:13:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 06:13:54 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
Message-ID: <m-k0RD0mgj_ttkH-tNFBIns8XRSyJZ1DkxP6OpfQ7Ek=.89dcd698-ff4f-4575-9818-19d1db091112@github.com>

On Fri, 4 Apr 2025 09:13:30 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
>> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
>> 
>> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
>> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
>> 
>> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
>> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/JWebServer.java line 66:

> 64:         setMaxConnectionsIfNotSet();
> 65: 
> 66:         int ec = SimpleFileServerImpl.start(new PrintWriter(System.out, true), "jwebserver", args);

I think you are looking for stdout.encoding here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24437#discussion_r2030514453

From alanb at openjdk.org  Mon Apr  7 06:48:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 06:48:55 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v6]
In-Reply-To: <FpwQiXKgwZOWkkHnSYhVi35mOhTqSKlv0hfIny3kwuA=.2b7f303c-9619-4b4e-9f5d-1311317627c8@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <FpwQiXKgwZOWkkHnSYhVi35mOhTqSKlv0hfIny3kwuA=.2b7f303c-9619-4b4e-9f5d-1311317627c8@github.com>
Message-ID: <ZMH1bnmHOhkkLu3JF3q30a51Oa2gdpavKejtGOl4Vy8=.4f01975a-02ed-4096-9d96-6df22e111252@github.com>

On Fri, 4 Apr 2025 19:22:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary SuppressWarnings and correct Deprecated annotation style

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1639:

> 1637:      */
> 1638:     @SuppressWarnings("removal")
> 1639:     static volatile RuntimePermission modifyThreadPermission;

This can be removed, it's not used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2030554666

From jpai at openjdk.org  Mon Apr  7 07:04:24 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 07:04:24 GMT
Subject: RFR: 8352895: UserCookie.java runs wrong test class
Message-ID: <oF2rYtEpyZiQMsIdT1Om_0fpKzF4z5TvBxd0quPJH5U=.0b66e5fa-46d7-4234-b953-6420000cc8cc@github.com>

Can I please get a review of this trivial test-only change which fixes the test definition to run the correct test class? This addresses https://bugs.openjdk.org/browse/JDK-8352895.

The test code can be cleaned up a lot more. In fact, I have a local version with additional clean ups. But I decided not to do those change now since I don't have a Java 1.5.x version which verifies that the test changes will still reproduce the original issue for which this test was introduced.

The test passes with this proposed change.

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

Commit messages:
 - 8352895: UserCookie.java runs wrong test class

Changes: https://git.openjdk.org/jdk/pull/24476/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24476&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352895
  Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24476/head:pull/24476

PR: https://git.openjdk.org/jdk/pull/24476

From jpai at openjdk.org  Mon Apr  7 07:22:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 07:22:50 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
Message-ID: <D5Uu28VHYjna36Ef-8m9a6HlYaDLlg6ebhpHKRQM8p0=.58e5b679-93b1-4536-b8dd-a5ac4e782315@github.com>

On Sat, 29 Mar 2025 17:27:20 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.

I would have preferred for the catch block to be changed to catch `IllegalArgumentException` instead of the current `NumberFormatException`, to closely align with the specification of `HexFormat.fromHexDigits(CharSequence string, int fromIndex, int toIndex)`, but I see that it has been discussed and the current version approved. 

Looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24314#pullrequestreview-2745751948

From vyazici at openjdk.org  Mon Apr  7 07:35:51 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Apr 2025 07:35:51 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <ij0giTwjyvA3qsia7jpmUoWHNVWcvQU3UrXaLMt1qpg=.453edc53-1a8b-45c2-95a6-d8b658828417@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
 <ij0giTwjyvA3qsia7jpmUoWHNVWcvQU3UrXaLMt1qpg=.453edc53-1a8b-45c2-95a6-d8b658828417@github.com>
Message-ID: <F1Cr4lBdLndZxKnXgL8E-KuDXM3QF15lrnVKhAjn58g=.adccc2bb-c8d6-4e71-8167-94516d8c42a6@github.com>

On Fri, 4 Apr 2025 15:01:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Remove timeout from `CountDownLatch::await` calls
>>  - Replace `@AutoClose` with a corresponding `@AfterEach` method
>>  - Remove IDE-specific `OptionalGetWithoutIsPresent` warning suppression
>>  - Improve `HttpConnection::label` JavaDoc
>>  - Start from 1 while labeling connections
>
> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 168:
> 
>> 166: 
>> 167:                         } catch (IOException ioe) {
>> 168:                             synchronized (ServerRequestPair.class) {
> 
> Is the synchronization intentional here?

@jaikiran, yes, otherwise the log line and the stack trace dump of consecutive handler failures were getting intertwined into each other.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2030620892

From jpai at openjdk.org  Mon Apr  7 07:48:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 07:48:05 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v7]
In-Reply-To: <HAqnjp3JUeRKdDV7epQTVuz9-Gif4v8j8Lx5c5ZO5C8=.9a3cc095-656b-4e28-84bf-94883403c6a2@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <HAqnjp3JUeRKdDV7epQTVuz9-Gif4v8j8Lx5c5ZO5C8=.9a3cc095-656b-4e28-84bf-94883403c6a2@github.com>
Message-ID: <aX_7hxJYSST_fQ-LHAw8U71ueOjG1nF3kts_1mk6MnA=.7b3a82d8-7daf-419e-a693-56009007e002@github.com>

On Mon, 7 Apr 2025 07:43:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use `othervm` in `@run`

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 35:

> 33: 
> 34: // `othervm` in `@run` is intentionally introduced, don't remove it!
> 35: // It helps with, in case `ForkJoinPool.commonPool()` gets corrupt by the test, reusing it again.

jtreg allows for `@comment` tag in the test definition. So you could replace this newly added code comment with something like:

@comment othervm usage is intentional since this test uses ForkJoinPool.commonPool()


just before the `@run ....` line in the test definition

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2030640583

From vyazici at openjdk.org  Mon Apr  7 07:48:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Apr 2025 07:48:05 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <h96xV24EilB9VUl7TD2WoLQSPPCiGTRZhq9I7sVmvYk=.9684910e-2c81-43bd-a212-f79644bc34d7@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
 <HZKiSGfhXPHvz-qEJGNON99MfIdLbIGUd0qzcuJwuo0=.59c7f542-b0d6-4ea2-b079-681faef069d4@github.com>
 <v694_bZNDg5zFXyub8oyM3fTwqMOC7D6x93TS3jpQiY=.1601608a-d7b0-48ce-8f0a-36dbec3328db@github.com>
 <h96xV24EilB9VUl7TD2WoLQSPPCiGTRZhq9I7sVmvYk=.9684910e-2c81-43bd-a212-f79644bc34d7@github.com>
Message-ID: <nGpOzQiUXp4T_3iD5INnbzUCoGbFvmCHW9p-5JZ4eL4=.bb39a247-07e2-48f0-9b3d-85ed6e5ffc16@github.com>

On Fri, 4 Apr 2025 15:03:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Another possibility is to run in /othervm mode - then we don't care...
>
> Yes, I think othervm would be fine. In fact, I was adding a review comment in another context, where I suspect we might be forced to use the othervm mode anyway.

Switched to `othervm` in cc70d926dbc867ecf8f3390c76ccb02888c8e8d8.

> I was adding a review comment in another context, where I suspect we might be forced to use the othervm mode anyway.

@jaikiran, curious, where is it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2030635525

From jpai at openjdk.org  Mon Apr  7 07:48:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 07:48:05 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <nGpOzQiUXp4T_3iD5INnbzUCoGbFvmCHW9p-5JZ4eL4=.bb39a247-07e2-48f0-9b3d-85ed6e5ffc16@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
 <HZKiSGfhXPHvz-qEJGNON99MfIdLbIGUd0qzcuJwuo0=.59c7f542-b0d6-4ea2-b079-681faef069d4@github.com>
 <v694_bZNDg5zFXyub8oyM3fTwqMOC7D6x93TS3jpQiY=.1601608a-d7b0-48ce-8f0a-36dbec3328db@github.com>
 <h96xV24EilB9VUl7TD2WoLQSPPCiGTRZhq9I7sVmvYk=.9684910e-2c81-43bd-a212-f79644bc34d7@github.com>
 <nGpOzQiUXp4T_3iD5INnbzUCoGbFvmCHW9p-5JZ4eL4=.bb39a247-07e2-48f0-9b3d-85ed6e5ffc16@github.com>
Message-ID: <aZmWLT0GO1wqmVlZINOsMTiVWvcBVf_ImQr5ylHCnBg=.db4444fb-f95c-4733-b86f-08e3180669a9@github.com>

On Mon, 7 Apr 2025 07:40:13 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Yes, I think othervm would be fine. In fact, I was adding a review comment in another context, where I suspect we might be forced to use the othervm mode anyway.
>
> Switched to `othervm` in cc70d926dbc867ecf8f3390c76ccb02888c8e8d8.
> 
>> I was adding a review comment in another context, where I suspect we might be forced to use the othervm mode anyway.
> 
> @jaikiran, curious, where is it?

Hello Volkan, this one https://github.com/openjdk/jdk/pull/24154#discussion_r2028999507

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2030636783

From vyazici at openjdk.org  Mon Apr  7 07:48:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Apr 2025 07:48:05 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v7]
In-Reply-To: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
Message-ID: <HAqnjp3JUeRKdDV7epQTVuz9-Gif4v8j8Lx5c5ZO5C8=.9a3cc095-656b-4e28-84bf-94883403c6a2@github.com>

> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
> 
> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Use `othervm` in `@run`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24154/files
  - new: https://git.openjdk.org/jdk/pull/24154/files/5b418fd7..cc70d926

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=05-06

  Stats: 6 lines in 1 file changed: 3 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24154/head:pull/24154

PR: https://git.openjdk.org/jdk/pull/24154

From vyazici at openjdk.org  Mon Apr  7 08:06:18 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Apr 2025 08:06:18 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v8]
In-Reply-To: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
Message-ID: <AaWmmc99ypGLA-b3OvGNLdQm3k8sm9UhzKoKz1Z6nlw=.15a28e88-5627-4d74-a251-794e06f0988c@github.com>

> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
> 
> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Rethrow exceptions caught in the handler

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24154/files
  - new: https://git.openjdk.org/jdk/pull/24154/files/cc70d926..4db85c31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=06-07

  Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24154/head:pull/24154

PR: https://git.openjdk.org/jdk/pull/24154

From vyazici at openjdk.org  Mon Apr  7 08:06:18 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Apr 2025 08:06:18 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <ij0giTwjyvA3qsia7jpmUoWHNVWcvQU3UrXaLMt1qpg=.453edc53-1a8b-45c2-95a6-d8b658828417@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
 <ij0giTwjyvA3qsia7jpmUoWHNVWcvQU3UrXaLMt1qpg=.453edc53-1a8b-45c2-95a6-d8b658828417@github.com>
Message-ID: <5A15chm0cJMEAx6Gt2jt90xOpq3CLFg57zWEkbCmiLM=.e45a0872-6860-420b-a15d-7c3fbc64dda2@github.com>

On Fri, 4 Apr 2025 15:02:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Remove timeout from `CountDownLatch::await` calls
>>  - Replace `@AutoClose` with a corresponding `@AfterEach` method
>>  - Remove IDE-specific `OptionalGetWithoutIsPresent` warning suppression
>>  - Improve `HttpConnection::label` JavaDoc
>>  - Start from 1 while labeling connections
>
> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 173:
> 
>> 171:                                         serverId, connectionKey, responseBody);
>> 172:                                 ioe.printStackTrace(System.out);
>> 173:                             }
> 
> Shouldn't we be rethrowing these exceptions from the handler to fail the request?

In 4db85c315f698c18a77545d5a2e732edf3199292, removed the `synchronized { ... }` and re-threw the exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2030677048

From vyazici at openjdk.org  Mon Apr  7 08:15:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Apr 2025 08:15:09 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v9]
In-Reply-To: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
Message-ID: <rY3f25A16s7ktXUjXZVEc1xcYX0ht_c9BuVtWpP-k5Q=.86005ec0-edbf-4bd7-804c-6ed3e3e274c5@github.com>

> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
> 
> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Improve test comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24154/files
  - new: https://git.openjdk.org/jdk/pull/24154/files/4db85c31..741a2dd0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=07-08

  Stats: 4 lines in 1 file changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24154/head:pull/24154

PR: https://git.openjdk.org/jdk/pull/24154

From vyazici at openjdk.org  Mon Apr  7 08:15:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Apr 2025 08:15:10 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v7]
In-Reply-To: <aX_7hxJYSST_fQ-LHAw8U71ueOjG1nF3kts_1mk6MnA=.7b3a82d8-7daf-419e-a693-56009007e002@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <HAqnjp3JUeRKdDV7epQTVuz9-Gif4v8j8Lx5c5ZO5C8=.9a3cc095-656b-4e28-84bf-94883403c6a2@github.com>
 <aX_7hxJYSST_fQ-LHAw8U71ueOjG1nF3kts_1mk6MnA=.7b3a82d8-7daf-419e-a693-56009007e002@github.com>
Message-ID: <GMmB4fiYUJF2IAiAxOa7rdLHtD8fUlVnbTmN6dlH7UI=.82ba3a5e-d885-4a58-8091-bd0666ed9732@github.com>

On Mon, 7 Apr 2025 07:43:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use `othervm` in `@run`
>
> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 35:
> 
>> 33: 
>> 34: // `othervm` in `@run` is intentionally introduced, don't remove it!
>> 35: // It helps with, in case `ForkJoinPool.commonPool()` gets corrupt by the test, reusing it again.
> 
> jtreg allows for `@comment` tag in the test definition. So you could replace this newly added code comment with something like:
> 
> @comment othervm usage is intentional since this test uses ForkJoinPool.commonPool()
> 
> 
> just before the `@run ....` line in the test definition

Thanks, updated in 741a2dd0a67dd70e38bdbccd6598c8757aba3ab4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2030690942

From vyazici at openjdk.org  Mon Apr  7 08:27:38 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Apr 2025 08:27:38 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v10]
In-Reply-To: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
Message-ID: <fg6Bi6PSV7aVcTXN2yz5Kn1Yl0VU2Vl4MgQ6JwdhrK8=.0a2138f8-a699-42d9-a5f5-fc21dfdb3b52@github.com>

> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
> 
> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Add -Djdk.httpclient.keepalive.timeout=120` to `@run`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24154/files
  - new: https://git.openjdk.org/jdk/pull/24154/files/741a2dd0..edc0c8d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=08-09

  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24154/head:pull/24154

PR: https://git.openjdk.org/jdk/pull/24154

From vyazici at openjdk.org  Mon Apr  7 08:27:38 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Apr 2025 08:27:38 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v6]
In-Reply-To: <AITGCXp_eE4WSflAAuxiqcyrySODzTU_d3FfYbQhv08=.88425889-5499-4d7c-8259-80871596be25@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <sNjevNSLqW4ErXVv-ugQAajX74nDhex86wabtq9KJuA=.dd179aab-eddf-4369-be5f-ac7cfbe09c92@github.com>
 <L2BPpb9NOPBaAwnKL8GFsXwnN3gYwMPKOt13WqeRy9A=.116b721c-1e2c-415f-a821-99736848eb41@github.com>
 <CubYJxZgrURSsvD5yrT4Tu8aebziaRab9HIypzG5lbE=.e28a031d-ec53-48c2-a9dd-7f4e27d5aa10@github.com>
 <a1xNzGbe34yEzRpxDoMTbg9dFqkXtGes9pCFsyycZW4=.1012e19e-9a3a-4ddd-9d98-0cb24783331d@github.com>
 <AITGCXp_eE4WSflAAuxiqcyrySODzTU_d3FfYbQhv08=.88425889-5499-4d7c-8259-80871596be25@github.com>
Message-ID: <FtnMJ8wQ4YRdr0Z3Num3yYvDo8CKPqWHluoUM1oCbi4=.432c5f88-179b-459b-883b-0f7bcedc6619@github.com>

On Fri, 4 Apr 2025 16:41:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Waiting for the test to fail due to this reason and then adjusting the timeout is fine with me.
>
> On the plus side - if we add the `-Djdk.httpclient.keepalive.timeout=120` now we might not have to deal with it later, and maybe it will give us a clue if the test ever fails due to this.

Added `-Djdk.httpclient.keepalive.timeout=120` in edc0c8d84e68505d054fa87b24316f456b15c4f0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2030712654

From jpai at openjdk.org  Mon Apr  7 09:11:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 09:11:03 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v10]
In-Reply-To: <fg6Bi6PSV7aVcTXN2yz5Kn1Yl0VU2Vl4MgQ6JwdhrK8=.0a2138f8-a699-42d9-a5f5-fc21dfdb3b52@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <fg6Bi6PSV7aVcTXN2yz5Kn1Yl0VU2Vl4MgQ6JwdhrK8=.0a2138f8-a699-42d9-a5f5-fc21dfdb3b52@github.com>
Message-ID: <yuRuwYoexFKnJvwEdJ_TE3zdeeu1-Iyx7KXSKFjJPFA=.f9391bc3-266a-430d-8ea2-d50534de3b7e@github.com>

On Mon, 7 Apr 2025 08:27:38 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add -Djdk.httpclient.keepalive.timeout=120` to `@run`

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 33:

> 31:  *
> 32:  * @comment `othervm` usage is intentional since this test uses `ForkJoinPool.commonPool()`
> 33:  * @comment There is no guarantee that sequential requests will be executed immediately one after the other.

Thank you for all the updates so far Volkan. This is overall looking good to me. One final nit about this comment. I think we can leave out a lot of this text and just state something like:


@comment use a higher idle timeout to increase the chances of
         the same connection being used for sequential HTTP requests

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2030799061

From jpai at openjdk.org  Mon Apr  7 09:14:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 09:14:00 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v4]
In-Reply-To: <qtk16ZOGajuWZNpHkB17AEZkwikT5aerOt-Lnif4DBo=.6fe74497-213c-465d-85e2-9e9d041c4db0@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <tAIXaR9JwJp5BPPLXFmao8eS-gRZj_Wm7c9v369IZ5I=.515939fe-d758-4188-838e-554817c12a10@github.com>
 <qjgXuVsn4GgXWo7GHg0u2blkrfT_h6r0wsn1Pt7oQZc=.012b7da6-a1ed-4d86-81ee-fc58e698a42f@github.com>
 <aeDyI4A1iU1EiSlcJMtrgubaUvITBvju5gcUE9sAi7c=.b7810218-94df-4a8e-976b-9912832cd94a@github.com>
 <qtk16ZOGajuWZNpHkB17AEZkwikT5aerOt-Lnif4DBo=.6fe74497-213c-465d-85e2-9e9d041c4db0@github.com>
Message-ID: <icwh4PzSjQkrCNDNqYT66u6eHW1q1lrcT5Msy247PAc=.777a5a00-8f39-46ef-b6ba-a499d7bf43d5@github.com>

On Fri, 4 Apr 2025 13:10:56 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> @jaikiran, what you're suggesting makes sense. I'm still exploring the interplay between the connection label and HTTP/3 server pushes. I will return back to your suggestion soon.
>
>> In this proposed form, no two connections in two different HttpClient instances will ever have the same `connectionLabel`.
> 
> Yes, but this is neither required by the connection label contract. That is, the contract doesn't say that they must have overlapping connection labels. It only states connection labels are unique-per-client. Our implementation is more stricter than that: unique-per-VM, but that is just an implementation detail.
> 
>> I think this counter should probably be present on the `HttpClientImpl` as an instance field.
> 
> I've given this approach an attempt. Though I find it difficult to reason about in the code that a counter _only_ `HttpConnection` uses is situated in `HttpClientImpl`, just to make two `HttpConnection`s from different `HttpClientImpl`s share the connection label.
> 
> I also agree with @dfuch that having a unique-per-VM connection label helps with troubleshooting too.
> 
> @jaikiran, unless you're strongly opinionated about this, I prefer to leave the connection label counter in `HttpConnection`. How shall we proceed?

I don't have a strong opinion nor can I think of any issues this current JVM level counter might cause. If necessary, we can reconsider this if/when any issue shows up, without impacting the specification of `HttpResponse.connectionLabel()`. The current form looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2030809033

From dfuchs at openjdk.org  Mon Apr  7 09:27:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Apr 2025 09:27:55 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <m-k0RD0mgj_ttkH-tNFBIns8XRSyJZ1DkxP6OpfQ7Ek=.89dcd698-ff4f-4575-9818-19d1db091112@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
 <m-k0RD0mgj_ttkH-tNFBIns8XRSyJZ1DkxP6OpfQ7Ek=.89dcd698-ff4f-4575-9818-19d1db091112@github.com>
Message-ID: <YFwbqzoS9wcYVpDKJfBcwN3e3_22GB1CQ3wIGWgGCwM=.d6f4674e-f5e0-4bd3-9f04-631c410ec4ab@github.com>

On Mon, 7 Apr 2025 06:11:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update full name
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/JWebServer.java line 66:
> 
>> 64:         setMaxConnectionsIfNotSet();
>> 65: 
>> 66:         int ec = SimpleFileServerImpl.start(new PrintWriter(System.out, true), "jwebserver", args);
> 
> I think you are looking for stdout.encoding here.

Are you suggesting changing this line @AlanBateman? The API doc of `PrintWriter(OutputStream, boolean)` says:

     * Creates a new PrintWriter from an existing OutputStream.  This
     * convenience constructor creates the necessary intermediate
     * OutputStreamWriter, which will convert characters into bytes using
     * the default charset, or where {@code out} is a {@code PrintStream},
     * the charset used by the print stream.

Isn't this what we want here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24437#discussion_r2030842093

From dfuchs at openjdk.org  Mon Apr  7 09:29:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Apr 2025 09:29:47 GMT
Subject: RFR: 8352895: UserCookie.java runs wrong test class
In-Reply-To: <oF2rYtEpyZiQMsIdT1Om_0fpKzF4z5TvBxd0quPJH5U=.0b66e5fa-46d7-4234-b953-6420000cc8cc@github.com>
References: <oF2rYtEpyZiQMsIdT1Om_0fpKzF4z5TvBxd0quPJH5U=.0b66e5fa-46d7-4234-b953-6420000cc8cc@github.com>
Message-ID: <JYCDE5I5HwlZHbv1webTvfKxNn8vOU99HDddXwSJnkw=.453f55ee-6e8b-4b73-8168-e4f5a49614d6@github.com>

On Mon, 7 Apr 2025 07:00:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial test-only change which fixes the test definition to run the correct test class? This addresses https://bugs.openjdk.org/browse/JDK-8352895.
> 
> The test code can be cleaned up a lot more. In fact, I have a local version with additional clean ups. But I decided not to do those change now since I don't have a Java 1.5.x version which verifies that the test changes will still reproduce the original issue for which this test was introduced.
> 
> The test passes with this proposed change.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24476#pullrequestreview-2746156543

From vyazici at openjdk.org  Mon Apr  7 09:31:47 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Apr 2025 09:31:47 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v11]
In-Reply-To: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
Message-ID: <0chWBC24_N7MtBS12c-dQjFEdZqvaj1U9yIEuaRNLJU=.c379f029-a46a-40ae-b662-5b963062a3bc@github.com>

> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
> 
> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Simplify comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24154/files
  - new: https://git.openjdk.org/jdk/pull/24154/files/edc0c8d8..db61a015

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=09-10

  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24154/head:pull/24154

PR: https://git.openjdk.org/jdk/pull/24154

From vyazici at openjdk.org  Mon Apr  7 09:31:49 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 7 Apr 2025 09:31:49 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v10]
In-Reply-To: <yuRuwYoexFKnJvwEdJ_TE3zdeeu1-Iyx7KXSKFjJPFA=.f9391bc3-266a-430d-8ea2-d50534de3b7e@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <fg6Bi6PSV7aVcTXN2yz5Kn1Yl0VU2Vl4MgQ6JwdhrK8=.0a2138f8-a699-42d9-a5f5-fc21dfdb3b52@github.com>
 <yuRuwYoexFKnJvwEdJ_TE3zdeeu1-Iyx7KXSKFjJPFA=.f9391bc3-266a-430d-8ea2-d50534de3b7e@github.com>
Message-ID: <4llMLWBpMn8JpxFZOCxwsqxcZg9hPzE9hREsOp8_Abs=.a2f26ff1-c4a1-4576-ac7d-3013b2a8fa4b@github.com>

On Mon, 7 Apr 2025 09:08:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add -Djdk.httpclient.keepalive.timeout=120` to `@run`
>
> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 33:
> 
>> 31:  *
>> 32:  * @comment `othervm` usage is intentional since this test uses `ForkJoinPool.commonPool()`
>> 33:  * @comment There is no guarantee that sequential requests will be executed immediately one after the other.
> 
> Thank you for all the updates so far Volkan. This is overall looking good to me. One final nit about this comment. I think we can leave out a lot of this text and just state something like:
> 
> 
> @comment use a higher idle timeout to increase the chances of
>          the same connection being used for sequential HTTP requests

Simplified as suggested in db61a01542ce12496721857bb8581683bff2cf81.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2030847366

From jpai at openjdk.org  Mon Apr  7 09:34:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 09:34:51 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v11]
In-Reply-To: <0chWBC24_N7MtBS12c-dQjFEdZqvaj1U9yIEuaRNLJU=.c379f029-a46a-40ae-b662-5b963062a3bc@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <0chWBC24_N7MtBS12c-dQjFEdZqvaj1U9yIEuaRNLJU=.c379f029-a46a-40ae-b662-5b963062a3bc@github.com>
Message-ID: <gMU7S4MuVJAUYQaLoOYCR6Znl9UC7e1dR7CTdkb9NUs=.ac036ab2-e66b-4355-ae56-29934551286f@github.com>

On Mon, 7 Apr 2025 09:31:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify comments

I don't have anything else. This looks good to me. Thank you for working on this enhancement and your patience during the review.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24154#pullrequestreview-2746171031

From alanb at openjdk.org  Mon Apr  7 09:35:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 09:35:58 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <YFwbqzoS9wcYVpDKJfBcwN3e3_22GB1CQ3wIGWgGCwM=.d6f4674e-f5e0-4bd3-9f04-631c410ec4ab@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
 <m-k0RD0mgj_ttkH-tNFBIns8XRSyJZ1DkxP6OpfQ7Ek=.89dcd698-ff4f-4575-9818-19d1db091112@github.com>
 <YFwbqzoS9wcYVpDKJfBcwN3e3_22GB1CQ3wIGWgGCwM=.d6f4674e-f5e0-4bd3-9f04-631c410ec4ab@github.com>
Message-ID: <xHXwtA-nadehXmqMC_PP3VuWOt4ucOWbiNjMrM3I3U4=.545c337e-d7ea-4dac-9c25-4de499396013@github.com>

On Mon, 7 Apr 2025 09:25:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/JWebServer.java line 66:
>> 
>>> 64:         setMaxConnectionsIfNotSet();
>>> 65: 
>>> 66:         int ec = SimpleFileServerImpl.start(new PrintWriter(System.out, true), "jwebserver", args);
>> 
>> I think you are looking for stdout.encoding here.
>
> Are you suggesting changing this line @AlanBateman? The API doc of `PrintWriter(OutputStream, boolean)` says:
> 
>      * Creates a new PrintWriter from an existing OutputStream.  This
>      * convenience constructor creates the necessary intermediate
>      * OutputStreamWriter, which will convert characters into bytes using
>      * the default charset, or where {@code out} is a {@code PrintStream},
>      * the charset used by the print stream.
> 
> Isn't this what we want here?

Just paging in the changes we did in JDK 10. They are the same thing as System.out will be created to use stdout.encoding. So you can ignore my comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24437#discussion_r2030855966

From dfuchs at openjdk.org  Mon Apr  7 09:42:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Apr 2025 09:42:54 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
Message-ID: <rhrzPFvNCLZcmeohypxse7p44JP87xm04DXO6Cp8lIk=.91b29105-5cd8-4aec-9755-7b5d344ff104@github.com>

On Fri, 4 Apr 2025 09:13:30 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
>> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
>> 
>> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
>> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
>> 
>> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
>> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

My tests came back green. Thanks for fixing this issue!

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24437#pullrequestreview-2746195722

From dfuchs at openjdk.org  Mon Apr  7 09:58:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Apr 2025 09:58:00 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
Message-ID: <pmET5pBFBPd39LQzFclTuexDz-2UUsiH9F_gSeSpUCU=.fc24048d-9b7e-43e0-9a89-35f45d651cd7@github.com>

On Sat, 29 Mar 2025 17:27:20 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.

Tests came back green - a few unrelated failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/24314#issuecomment-2782760557

From jpai at openjdk.org  Mon Apr  7 13:15:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 13:15:49 GMT
Subject: RFR: 8353278: Consolidate local file URL checks in jar: and file:
 URL schemes
In-Reply-To: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
References: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
Message-ID: <pRjCOznOKFPgBBGeWfgYuiUkKi9hXmly5McePSFn_rg=.a15c2a3f-715a-4f09-87db-df3062274afb@github.com>

On Mon, 31 Mar 2025 14:46:32 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this cleanup PR which consolidates 'local file' URL checks across the 'file:' and 'jar:' URL scheme implementations and defines this check in terms of RFC 8089, Section 2.
> 
> This PR:
> 
> * Moves `URLJarFile.isFileURL` to `sun.net.www.ParseUtil` where it is documented according to RFC 8089 and given the more suitable name `isLocalFileURL`
> * Updates `isLocalFileURL` to simplify an `if (x) return true;` statement to `return x;`
> * Updates `URLJarFile.getJarFile` and `JarFileFactory.getOrCreate` to use `isLocalFileURL`
> * Updates `JarFileFactory.urlFor` to use `isLocalFileURL` (while maintaining and documenting the historical and subtly different non-treatment of '~' as an alias for 'localhost')
> * Updates `sun.net.www.protocol.file.Handler.openConnection` to use `isLocalFileURL` in windows/unix implementations
> 
> This is a pure cleanup / refactoring PR, no tests are updated here. Existing testing in this area seems sparse, so I have tried to limit the number of code tweaks to a minimium to make reviews easier.
> 
> Testing: GHA runs green, as well as tier2 on MacOS.

Hello Eirik, these changes look good to me and merely centralizing the logic to one single `ParseUtil.isLocalFileURL()` method. Thank you for cleaning this up.

The copyright year on `URLJarFile.java` will need an update.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24332#pullrequestreview-2746779221

From eirbjo at openjdk.org  Mon Apr  7 13:26:45 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Apr 2025 13:26:45 GMT
Subject: RFR: 8353278: Consolidate local file URL checks in jar: and file:
 URL schemes [v2]
In-Reply-To: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
References: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
Message-ID: <FNnTXGGKi7h6D3gQK5ew505BLbcx_BXbTkeX4X-cTo8=.b5f97fbe-8709-4a14-b767-6473059d3011@github.com>

> Please help review this cleanup PR which consolidates 'local file' URL checks across the 'file:' and 'jar:' URL scheme implementations and defines this check in terms of RFC 8089, Section 2.
> 
> This PR:
> 
> * Moves `URLJarFile.isFileURL` to `sun.net.www.ParseUtil` where it is documented according to RFC 8089 and given the more suitable name `isLocalFileURL`
> * Updates `isLocalFileURL` to simplify an `if (x) return true;` statement to `return x;`
> * Updates `URLJarFile.getJarFile` and `JarFileFactory.getOrCreate` to use `isLocalFileURL`
> * Updates `JarFileFactory.urlFor` to use `isLocalFileURL` (while maintaining and documenting the historical and subtly different non-treatment of '~' as an alias for 'localhost')
> * Updates `sun.net.www.protocol.file.Handler.openConnection` to use `isLocalFileURL` in windows/unix implementations
> 
> This is a pure cleanup / refactoring PR, no tests are updated here. Existing testing in this area seems sparse, so I have tried to limit the number of code tweaks to a minimium to make reviews easier.
> 
> Testing: GHA runs green, as well as tier2 on MacOS.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24332/files
  - new: https://git.openjdk.org/jdk/pull/24332/files/68fe3458..752a2132

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24332&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24332&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24332/head:pull/24332

PR: https://git.openjdk.org/jdk/pull/24332

From jpai at openjdk.org  Mon Apr  7 13:26:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 13:26:46 GMT
Subject: RFR: 8353278: Consolidate local file URL checks in jar: and file:
 URL schemes [v2]
In-Reply-To: <FNnTXGGKi7h6D3gQK5ew505BLbcx_BXbTkeX4X-cTo8=.b5f97fbe-8709-4a14-b767-6473059d3011@github.com>
References: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
 <FNnTXGGKi7h6D3gQK5ew505BLbcx_BXbTkeX4X-cTo8=.b5f97fbe-8709-4a14-b767-6473059d3011@github.com>
Message-ID: <ntM48AEHfDbWV8lcA3t0g9YKYiAoY5cQrG3FhlrTzPg=.8880d350-e497-42ce-8390-b8f14b0bc782@github.com>

On Mon, 7 Apr 2025 13:22:56 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this cleanup PR which consolidates 'local file' URL checks across the 'file:' and 'jar:' URL scheme implementations and defines this check in terms of RFC 8089, Section 2.
>> 
>> This PR:
>> 
>> * Moves `URLJarFile.isFileURL` to `sun.net.www.ParseUtil` where it is documented according to RFC 8089 and given the more suitable name `isLocalFileURL`
>> * Updates `isLocalFileURL` to simplify an `if (x) return true;` statement to `return x;`
>> * Updates `URLJarFile.getJarFile` and `JarFileFactory.getOrCreate` to use `isLocalFileURL`
>> * Updates `JarFileFactory.urlFor` to use `isLocalFileURL` (while maintaining and documenting the historical and subtly different non-treatment of '~' as an alias for 'localhost')
>> * Updates `sun.net.www.protocol.file.Handler.openConnection` to use `isLocalFileURL` in windows/unix implementations
>> 
>> This is a pure cleanup / refactoring PR, no tests are updated here. Existing testing in this area seems sparse, so I have tried to limit the number of code tweaks to a minimium to make reviews easier.
>> 
>> Testing: GHA runs green, as well as tier2 on MacOS.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24332#pullrequestreview-2746806517

From eirbjo at openjdk.org  Mon Apr  7 13:26:46 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Apr 2025 13:26:46 GMT
Subject: RFR: 8353278: Consolidate local file URL checks in jar: and file:
 URL schemes [v2]
In-Reply-To: <pRjCOznOKFPgBBGeWfgYuiUkKi9hXmly5McePSFn_rg=.a15c2a3f-715a-4f09-87db-df3062274afb@github.com>
References: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
 <pRjCOznOKFPgBBGeWfgYuiUkKi9hXmly5McePSFn_rg=.a15c2a3f-715a-4f09-87db-df3062274afb@github.com>
Message-ID: <kibH97YH3xRcLm-agckNe8dFXiRwORrZGTesrcGo1gI=.74d603d4-bbf1-4413-a31c-c5a9e9125798@github.com>

On Mon, 7 Apr 2025 13:13:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Eirik, these changes look good to me and merely centralizing the logic to one single `ParseUtil.isLocalFileURL()` method. Thank you for cleaning this up.

Thank you for verifying!

> The copyright year on `URLJarFile.java` will need an update.

Ooops, updated in latest commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/24332#issuecomment-2783320087

From dfuchs at openjdk.org  Mon Apr  7 13:33:01 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Apr 2025 13:33:01 GMT
Subject: RFR: 8353278: Consolidate local file URL checks in jar: and file:
 URL schemes [v2]
In-Reply-To: <FNnTXGGKi7h6D3gQK5ew505BLbcx_BXbTkeX4X-cTo8=.b5f97fbe-8709-4a14-b767-6473059d3011@github.com>
References: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
 <FNnTXGGKi7h6D3gQK5ew505BLbcx_BXbTkeX4X-cTo8=.b5f97fbe-8709-4a14-b767-6473059d3011@github.com>
Message-ID: <3z20T4V9heqGnQv_hYuy4RfjXk4xeL6XR384aW_ryN4=.01c40e83-3850-4c3d-bfd5-e9c04cd2ad98@github.com>

On Mon, 7 Apr 2025 13:26:45 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this cleanup PR which consolidates 'local file' URL checks across the 'file:' and 'jar:' URL scheme implementations and defines this check in terms of RFC 8089, Section 2.
>> 
>> This PR:
>> 
>> * Moves `URLJarFile.isFileURL` to `sun.net.www.ParseUtil` where it is documented according to RFC 8089 and given the more suitable name `isLocalFileURL`
>> * Updates `isLocalFileURL` to simplify an `if (x) return true;` statement to `return x;`
>> * Updates `URLJarFile.getJarFile` and `JarFileFactory.getOrCreate` to use `isLocalFileURL`
>> * Updates `JarFileFactory.urlFor` to use `isLocalFileURL` (while maintaining and documenting the historical and subtly different non-treatment of '~' as an alias for 'localhost')
>> * Updates `sun.net.www.protocol.file.Handler.openConnection` to use `isLocalFileURL` in windows/unix implementations
>> 
>> This is a pure cleanup / refactoring PR, no tests are updated here. Existing testing in this area seems sparse, so I have tried to limit the number of code tweaks to a minimium to make reviews easier.
>> 
>> Testing: GHA runs green, as well as tier2 on MacOS.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Good to go!

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24332#pullrequestreview-2746835741

From dfuchs at openjdk.org  Mon Apr  7 14:04:08 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Apr 2025 14:04:08 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
In-Reply-To: <2Npic-M0k5PeOIVi10Vswokk6naB8u0fN2GQQKe1bNE=.49d4f6bc-f218-4e90-a85e-a0744ca4701c@github.com>
References: <2Npic-M0k5PeOIVi10Vswokk6naB8u0fN2GQQKe1bNE=.49d4f6bc-f218-4e90-a85e-a0744ca4701c@github.com>
Message-ID: <M8ZDUjP9HXGsKb9XR8RmBV3k31FyvirHatAzvS1u3Ok=.ac23a9aa-33c2-4681-a354-c878f1fdeb3c@github.com>

On Sat, 5 Apr 2025 10:23:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this PR which improves `HttpServer::stop` termination timing to better fit user expectations.
> 
> This PR:
> 
> * Makes `ServerImpl::stop` continue without delay when there are no active exchanges during shutdown
> * Attempts to interrupt the dispatcher thread before joining it, giving long-living interruptible exchanges a chance to finish  early
> * Adds testing for boundary conditions with or without an active exchange, delay occurring before exhange completes and exchange completing before delay.
> 
> Additionally, `ServerImpl::stop` is updated to use `System::nanotime` instead of `System::currentTimeMillis` when calculating wait times.
> 
> The test relies on timing to assert the order of events. Not perfect, but it seems to work.
> 
> (This part of the code base is rather new to me. A bit of hand-holding should be expected when reviewing this PR)

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 238:

> 236:         selector.wakeup();
> 237:         long latest = System.nanoTime() + Duration.ofSeconds(delay).toNanos();
> 238:         while (activeExchanges() > 0 && System.nanoTime() < latest) {

I don't think that works unfortunately. We need something that takes into account that an exchange may have been started but hasn't reached the point where startExchange has been called. 

The problem is that exchangeCount is incremeted asynchronously in the ExchangeImpl constructor, and the ExchangeImpl is created by the Exchange::run method - which is run asynchronoously in the executor (submitted by the dispacher thread).

Possibly posting a StopRequested event to the dispatcher thread, and have the dispacther thread switch finished = true when is sees the StopRequested event and notices that allConnections only contains idleConnections (in which case we could also assert that exchangeCount == 0).

Unless I'm not mistaken this is not going to be a trivial fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24467#discussion_r2031318272

From duke at openjdk.org  Mon Apr  7 14:05:05 2025
From: duke at openjdk.org (Daishi Tabata)
Date: Mon, 7 Apr 2025 14:05:05 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
Message-ID: <ZnHy2CUlFvjhr4QYk9Gkk4qQhk69Nd_hPwDz3IBK85M=.62d69615-561c-438a-9a17-849160900246@github.com>

On Fri, 4 Apr 2025 09:13:30 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
>> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
>> 
>> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
>> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
>> 
>> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
>> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24437#issuecomment-2783447211

From duke at openjdk.org  Mon Apr  7 14:05:05 2025
From: duke at openjdk.org (duke)
Date: Mon, 7 Apr 2025 14:05:05 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
Message-ID: <U1y6scbrkHtDjrggb8r3UwhbXJS-iFBMCkDsbZNf3Zg=.f2fb9076-d7dd-4665-a2da-9e72ef1a0249@github.com>

On Fri, 4 Apr 2025 09:13:30 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
>> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
>> 
>> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
>> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
>> 
>> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
>> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

@tabata-d 
Your change (at version 0bc8e196e88fa5c788c6076b81237a1f24ff8014) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24437#issuecomment-2783452079

From dfuchs at openjdk.org  Mon Apr  7 14:21:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Apr 2025 14:21:57 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
In-Reply-To: <2Npic-M0k5PeOIVi10Vswokk6naB8u0fN2GQQKe1bNE=.49d4f6bc-f218-4e90-a85e-a0744ca4701c@github.com>
References: <2Npic-M0k5PeOIVi10Vswokk6naB8u0fN2GQQKe1bNE=.49d4f6bc-f218-4e90-a85e-a0744ca4701c@github.com>
Message-ID: <_g_Ju0uoLsHIfieGpnDnzxCY3-sQDAdZUGODSu18Ms0=.5f3ef4b1-fdb6-4e8f-814b-a22483ff3d49@github.com>

On Sat, 5 Apr 2025 10:23:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this PR which improves `HttpServer::stop` termination timing to better fit user expectations.
> 
> This PR:
> 
> * Makes `ServerImpl::stop` continue without delay when there are no active exchanges during shutdown
> * Attempts to interrupt the dispatcher thread before joining it, giving long-living interruptible exchanges a chance to finish  early
> * Adds testing for boundary conditions with or without an active exchange, delay occurring before exhange completes and exchange completing before delay.
> 
> Additionally, `ServerImpl::stop` is updated to use `System::nanotime` instead of `System::currentTimeMillis` when calculating wait times.
> 
> The test relies on timing to assert the order of events. Not perfect, but it seems to work.
> 
> (This part of the code base is rather new to me. A bit of hand-holding should be expected when reviewing this PR)

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 238:

> 236:         selector.wakeup();
> 237:         long latest = System.nanoTime() + Duration.ofSeconds(delay).toNanos();
> 238:         while (activeExchanges() > 0 && System.nanoTime() < latest) {

Also the arithmetic is dubious since `System.nanoTime() + Duration.ofSeconds(delay).toNanos();` could overflow. You never want to compare `val1 < val2` - use `val2 - val1 > 0` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24467#discussion_r2031352645

From eirbjo at openjdk.org  Mon Apr  7 14:35:11 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Apr 2025 14:35:11 GMT
Subject: RFR: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
In-Reply-To: <M8ZDUjP9HXGsKb9XR8RmBV3k31FyvirHatAzvS1u3Ok=.ac23a9aa-33c2-4681-a354-c878f1fdeb3c@github.com>
References: <2Npic-M0k5PeOIVi10Vswokk6naB8u0fN2GQQKe1bNE=.49d4f6bc-f218-4e90-a85e-a0744ca4701c@github.com>
 <M8ZDUjP9HXGsKb9XR8RmBV3k31FyvirHatAzvS1u3Ok=.ac23a9aa-33c2-4681-a354-c878f1fdeb3c@github.com>
Message-ID: <jCjPY0YHs0_ijTn6ElXeZmpU7P52SLvA-ReD7xfjBT0=.4bb6ffc9-c2fd-401e-9e89-06f5b168fe65@github.com>

On Mon, 7 Apr 2025 14:00:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Unless I'm not mistaken this is not going to be a trivial fix.

Alright, I'll convert this to a draft PR for now. I may explore solutions, but it seems a full fix could be above my pay grade.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24467#discussion_r2031380747

From eirbjo at openjdk.org  Mon Apr  7 15:26:34 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Apr 2025 15:26:34 GMT
Subject: Integrated: 8353278: Consolidate local file URL checks in jar: and
 file: URL schemes
In-Reply-To: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
References: <ahXqdO78WlnY8XtscQP0M_RqKBoTyFV_zkKJpzBfrrk=.86164dd2-5af7-4b61-9f61-cbf1df6887f3@github.com>
Message-ID: <AN4uWJSf5kVWdApoxM6NXypDgTqa2Yv_awfN0yUcVB0=.c230b8b2-b8e4-4e79-8af2-78f915052d34@github.com>

On Mon, 31 Mar 2025 14:46:32 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this cleanup PR which consolidates 'local file' URL checks across the 'file:' and 'jar:' URL scheme implementations and defines this check in terms of RFC 8089, Section 2.
> 
> This PR:
> 
> * Moves `URLJarFile.isFileURL` to `sun.net.www.ParseUtil` where it is documented according to RFC 8089 and given the more suitable name `isLocalFileURL`
> * Updates `isLocalFileURL` to simplify an `if (x) return true;` statement to `return x;`
> * Updates `URLJarFile.getJarFile` and `JarFileFactory.getOrCreate` to use `isLocalFileURL`
> * Updates `JarFileFactory.urlFor` to use `isLocalFileURL` (while maintaining and documenting the historical and subtly different non-treatment of '~' as an alias for 'localhost')
> * Updates `sun.net.www.protocol.file.Handler.openConnection` to use `isLocalFileURL` in windows/unix implementations
> 
> This is a pure cleanup / refactoring PR, no tests are updated here. Existing testing in this area seems sparse, so I have tried to limit the number of code tweaks to a minimium to make reviews easier.
> 
> Testing: GHA runs green, as well as tier2 on MacOS.

This pull request has now been integrated.

Changeset: 9a391f44
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a391f44e038d6c15a7872164bd3099edad93c8d
Stats:     47 lines in 5 files changed: 18 ins; 17 del; 12 mod

8353278: Consolidate local file URL checks in jar: and file: URL schemes

Reviewed-by: dfuchs, jpai

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

PR: https://git.openjdk.org/jdk/pull/24332

From myankelevich at openjdk.org  Mon Apr  7 16:05:58 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 7 Apr 2025 16:05:58 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v3]
In-Reply-To: <CvYBKWdfLP9pI6wTgF1N1m-2oB3wfu5Q91yWJwHRIvk=.d2be164d-a095-4faa-ab49-a30a611904fb@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
 <CvYBKWdfLP9pI6wTgF1N1m-2oB3wfu5Q91yWJwHRIvk=.d2be164d-a095-4faa-ab49-a30a611904fb@github.com>
Message-ID: <t4yUtA82dfiwtliDbKYTRwaew5jWFGTz4peUylm_2II=.d420f27f-60bd-4ef4-8f8a-bf9336ae7f35@github.com>

On Thu, 6 Feb 2025 15:54:47 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * fully automated the test
>> * removed the race condition
>> * client on a thread and server on a thread options are now run together automatically
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment changes

Still needs a security libraries approval

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

PR Comment: https://git.openjdk.org/jdk/pull/23469#issuecomment-2783869367

From rriggs at openjdk.org  Mon Apr  7 17:18:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 7 Apr 2025 17:18:40 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v7]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <FPgMhmaele4ojOh_5Bl80dEE3DUT68wO1cOMYpWtz0U=.47e6ff61-08dd-4626-8403-0e2ef0bf6e7b@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
  Remove dead code from ForkJoinPool.
  Add @SuppressWarnings("remove")

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/9a9417a7..322c5938

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=05-06

  Stats: 20 lines in 4 files changed: 11 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From rriggs at openjdk.org  Mon Apr  7 18:40:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 7 Apr 2025 18:40:35 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Roger Riggs 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 10 additional commits since the last revision:

 - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
   SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
 - Merge branch 'master' into 8353641-deprecate-premission-classes
 - Missing suppresswarnings
 - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
   Remove dead code from ForkJoinPool.
   Add @SuppressWarnings("remove")
 - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
 - Update copyright in WindowsFileCopy
 - Remove unused import of LinkPermission
 - Updated style of @Deprecated to match most existing @Deprecated annotations
   `since` comes before `forRemoval`
   No spaces around `=`
 - Add SuppressWarnings to a Windows source missed earlier.
 - 8353641: Deprecate core library permission classes for removal
   
   Now that the Security Manager is permanently disabled, the following permission classes
   in the core libraries area can be deprecated for removal as they are no longer useful:
   FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
   RuntimePermission, and SerializablePermission
   
   @Deprecated(forRemoval = true, since="25")
   Is added to each class and the existing @apiNote is converted to @deprected

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/322c5938..6d3f003d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=06-07

  Stats: 10986 lines in 240 files changed: 8087 ins; 2384 del; 515 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

PR: https://git.openjdk.org/jdk/pull/24444

From jpai at openjdk.org  Tue Apr  8 00:37:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Apr 2025 00:37:16 GMT
Subject: RFR: 8352895: UserCookie.java runs wrong test class
In-Reply-To: <oF2rYtEpyZiQMsIdT1Om_0fpKzF4z5TvBxd0quPJH5U=.0b66e5fa-46d7-4234-b953-6420000cc8cc@github.com>
References: <oF2rYtEpyZiQMsIdT1Om_0fpKzF4z5TvBxd0quPJH5U=.0b66e5fa-46d7-4234-b953-6420000cc8cc@github.com>
Message-ID: <DcYATXf-z5T5_XF1VJ343qqvtP9_58j_KSXnAaXgm0Y=.69c46055-c76a-453c-b160-83884e78dd73@github.com>

On Mon, 7 Apr 2025 07:00:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial test-only change which fixes the test definition to run the correct test class? This addresses https://bugs.openjdk.org/browse/JDK-8352895.
> 
> The test code can be cleaned up a lot more. In fact, I have a local version with additional clean ups. But I decided not to do those change now since I don't have a Java 1.5.x version which verifies that the test changes will still reproduce the original issue for which this test was introduced.
> 
> The test passes with this proposed change.

Thank you Daniel for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/24476#issuecomment-2784932080

From jpai at openjdk.org  Tue Apr  8 00:37:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Apr 2025 00:37:17 GMT
Subject: Integrated: 8352895: UserCookie.java runs wrong test class
In-Reply-To: <oF2rYtEpyZiQMsIdT1Om_0fpKzF4z5TvBxd0quPJH5U=.0b66e5fa-46d7-4234-b953-6420000cc8cc@github.com>
References: <oF2rYtEpyZiQMsIdT1Om_0fpKzF4z5TvBxd0quPJH5U=.0b66e5fa-46d7-4234-b953-6420000cc8cc@github.com>
Message-ID: <Uvw6VBpC8XQqN-pUZ54tVPDPmzztJuYH9nq-mktgLkA=.bfa13646-5d33-419b-b2fb-0cd86caa38ee@github.com>

On Mon, 7 Apr 2025 07:00:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial test-only change which fixes the test definition to run the correct test class? This addresses https://bugs.openjdk.org/browse/JDK-8352895.
> 
> The test code can be cleaned up a lot more. In fact, I have a local version with additional clean ups. But I decided not to do those change now since I don't have a Java 1.5.x version which verifies that the test changes will still reproduce the original issue for which this test was introduced.
> 
> The test passes with this proposed change.

This pull request has now been integrated.

Changeset: edaeb4b2
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edaeb4b2da7c7a49ea3f3baebc7a072b56088e34
Stats:     5 lines in 1 file changed: 2 ins; 2 del; 1 mod

8352895: UserCookie.java runs wrong test class

Reviewed-by: dfuchs

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

PR: https://git.openjdk.org/jdk/pull/24476

From alanb at openjdk.org  Tue Apr  8 06:44:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Apr 2025 06:44:15 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>
Message-ID: <fPf4I6lx1VDVOXn0m756xJFfn5xwJ_hjYjzGJvmmdIE=.1b3ac35e-2438-4d6b-9a0b-3f52e2fe17f0@github.com>

On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs 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 10 additional commits since the last revision:
> 
>  - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
>    SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
>  - Merge branch 'master' into 8353641-deprecate-premission-classes
>  - Missing suppresswarnings
>  - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
>    Remove dead code from ForkJoinPool.
>    Add @SuppressWarnings("remove")
>  - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
>  - Update copyright in WindowsFileCopy
>  - Remove unused import of LinkPermission
>  - Updated style of @Deprecated to match most existing @Deprecated annotations
>    `since` comes before `forRemoval`
>    No spaces around `=`
>  - Add SuppressWarnings to a Windows source missed earlier.
>  - 8353641: Deprecate core library permission classes for removal
>    
>    Now that the Security Manager is permanently disabled, the following permission classes
>    in the core libraries area can be deprecated for removal as they are no longer useful:
>    FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
>    RuntimePermission, and SerializablePermission
>    
>    @Deprecated(forRemoval = true, since="25")
>    Is added to each class and the existing @apiNote is converted to @deprected

src/java.base/share/classes/jdk/internal/access/JavaIOFilePermissionAccess.java line 49:

> 47:      */
> 48:     @SuppressWarnings("removal")
> 49:     FilePermission newPermUsingAltPath(FilePermission input);

I assume JavaIOFilePermissionAccess can be removed, nothing should be using this now.

src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java line 443:

> 441:     @SuppressWarnings("removal")
> 442:     private void defineTransletClasses()
> 443:         throws TransformerConfigurationException {

In passing, the PermissionCollection used to construct the PD here is no longer needed. If this is cleaned up then the SW wouldn't be needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2032494012
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2032493150

From duke at openjdk.org  Tue Apr  8 12:39:39 2025
From: duke at openjdk.org (serhiysachkov)
Date: Tue, 8 Apr 2025 12:39:39 GMT
Subject: RFR: 8353847: Remove extra args to System.out.printf in
 open/test/jsk/java/net/httpclient tests
Message-ID: <VyexoBS2cXP_Gk9p9IKeuoH-RXgnVCm06F7RX0O2iaM=.d97692bc-3479-43e2-878b-e84f972fac45@github.com>

Remove extra args to System.out.printf in open/test/jsk/java/net/httpclient tests

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

Commit messages:
 - 8353847: Remove extra args to System.out.printf in open/test/jsk/java/net/httpclient tests

Changes: https://git.openjdk.org/jdk/pull/24507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24507&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353847
  Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24507/head:pull/24507

PR: https://git.openjdk.org/jdk/pull/24507

From dfuchs at openjdk.org  Tue Apr  8 13:19:11 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 8 Apr 2025 13:19:11 GMT
Subject: RFR: 8353847: Remove extra args to System.out.printf in
 open/test/jsk/java/net/httpclient tests
In-Reply-To: <VyexoBS2cXP_Gk9p9IKeuoH-RXgnVCm06F7RX0O2iaM=.d97692bc-3479-43e2-878b-e84f972fac45@github.com>
References: <VyexoBS2cXP_Gk9p9IKeuoH-RXgnVCm06F7RX0O2iaM=.d97692bc-3479-43e2-878b-e84f972fac45@github.com>
Message-ID: <_VDViInt7X6qgSAiqq_7tHffZwpDK34JHP-8AqKjHK4=.6cb40cef-3bf7-4234-a253-4d5c811477a4@github.com>

On Tue, 8 Apr 2025 12:33:52 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Remove extra args to System.out.printf in open/test/jsk/java/net/httpclient tests

Marked as reviewed by dfuchs (Reviewer).

@serhiysachkov while your at it can you fix the issue title (jsk => jdk) and then update the PR title accordingly? Thanks!

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

PR Review: https://git.openjdk.org/jdk/pull/24507#pullrequestreview-2749936477
PR Comment: https://git.openjdk.org/jdk/pull/24507#issuecomment-2786403970

From duke at openjdk.org  Tue Apr  8 13:19:11 2025
From: duke at openjdk.org (duke)
Date: Tue, 8 Apr 2025 13:19:11 GMT
Subject: RFR: 8353847: Remove extra args to System.out.printf in
 open/test/jsk/java/net/httpclient tests
In-Reply-To: <VyexoBS2cXP_Gk9p9IKeuoH-RXgnVCm06F7RX0O2iaM=.d97692bc-3479-43e2-878b-e84f972fac45@github.com>
References: <VyexoBS2cXP_Gk9p9IKeuoH-RXgnVCm06F7RX0O2iaM=.d97692bc-3479-43e2-878b-e84f972fac45@github.com>
Message-ID: <4QXlmAM9A2RYGfO92c8VA7su6FUVMa3lUjhFtGtUaYU=.c1aa9c4d-f078-4c7f-a154-c81cd6ca0f12@github.com>

On Tue, 8 Apr 2025 12:33:52 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Remove extra args to System.out.printf in open/test/jsk/java/net/httpclient tests

@serhiysachkov 
Your change (at version 8dea22e4088f5f09cecb4886d50b0b41a28a0411) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24507#issuecomment-2786407666

From Shruthi.Shruthi1 at ibm.com  Tue Apr  8 12:33:44 2025
From: Shruthi.Shruthi1 at ibm.com (Shruthi .)
Date: Tue, 8 Apr 2025 12:33:44 +0000
Subject: Suggestion needed to port the fix to JDK17 and JDK11S
In-Reply-To: <a8254bdf-a678-4ceb-94d7-77253372101e@oracle.com>
References: <SJ0PR15MB4663E34342AC2F9AC8A876AACCFC2@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <cb761fa6-3b2e-4752-846d-3a7ff28861ae@oracle.com>
 <SJ0PR15MB4663D70B7F45120E4B75956DCCC62@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <SJ0PR15MB4663242E65CB63DD64272DE0CCC32@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <2633ad7f-c278-4f88-bcbc-ec8211d7ee48@oracle.com>
 <SJ0PR15MB46631AD45E4B42C4A39F008DCCC22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <ef07a775-f954-4051-a0e9-59100c7715c3@oracle.com>
 <SJ0PR15MB46638A0DE787D32EFABAA8E1CCD52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <ec39b10b-5271-41cf-aa7f-d3f915ee0a18@oracle.com>
 <SJ0PR15MB4663123A5C03544060DC27E9CCD52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <8861a349-6446-4326-b168-e9594aeef70b@oracle.com>
 <SJ0PR15MB4663C04ADCBC69EFEF78C71CCCD22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <d79fdfb8-e717-4c73-8c0c-3fae0fadce01@oracle.com>
 <SJ0PR15MB4663218DFB930F6B6EF9F211CCD22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <a8254bdf-a678-4ceb-94d7-77253372101e@oracle.com>
Message-ID: <SJ0PR15MB4663B9DE26624483CA466C4CCCB52@SJ0PR15MB4663.namprd15.prod.outlook.com>

Hi Alan,

I was able to successfully build the OpenJDK headstream with the preClose reordering patch, which you have shared: pending_signals.patch<https://bugs.openjdk.org/secure/attachment/113740/pending_signals.patch>.
To validate the build, I executed the Race.java testcase 500 times, and it passed consistently without any failures.
For comparison, I ran the same testcase without the patch, and it failed on the 86th iteration.

Thanks
Shruthi
________________________________
From: Alan Bateman <alan.bateman at oracle.com>
Sent: Friday, March 14, 2025 3:00 PM
To: Shruthi . <Shruthi.Shruthi1 at ibm.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Cc: Syed Moinudeen <smoinud1 at in.ibm.com>; SREENIVAS MAKINEEDI <sreeni at us.ibm.com>
Subject: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11S

On 14/03/2025 09:?22, Shruthi . wrote: The issue which we are seeing is not reproducible in JDK21 or higher version Okay, so you might be chasing a different issue? For the JDK then maybe we need more stress tests for async close, maybe that

On 14/03/2025 09:22, Shruthi . wrote:
The issue which we are seeing is not reproducible in JDK21 or higher version

Okay, so you might be chasing a different issue? For the JDK then maybe we need more stress tests for async close, maybe that would help you reproduce it with main line.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250408/c2d6cc4b/attachment.htm>

From mullan at openjdk.org  Tue Apr  8 14:23:06 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Apr 2025 14:23:06 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v3]
In-Reply-To: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
Message-ID: <OSc3QmBnvBvNITU3-t-4EYjK09r42aa5T3rvaztKbgI=.d7af7086-1839-42bf-9bd6-18b0d5eda683@github.com>

> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Fix build error; add removal annotation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24445/files
  - new: https://git.openjdk.org/jdk/pull/24445/files/8dae2f8d..cecd9287

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24445/head:pull/24445

PR: https://git.openjdk.org/jdk/pull/24445

From rriggs at openjdk.org  Tue Apr  8 15:05:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Apr 2025 15:05:35 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v3]
In-Reply-To: <OSc3QmBnvBvNITU3-t-4EYjK09r42aa5T3rvaztKbgI=.d7af7086-1839-42bf-9bd6-18b0d5eda683@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
 <OSc3QmBnvBvNITU3-t-4EYjK09r42aa5T3rvaztKbgI=.d7af7086-1839-42bf-9bd6-18b0d5eda683@github.com>
Message-ID: <3DjiAo-0RHErmFMxtXjOQkl9N14GEqyDMEpzFk-YyEk=.c4d9615b-d33d-4ee8-b189-b0a86fb6f006@github.com>

On Tue, 8 Apr 2025 14:23:06 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
>> 
>> The current API note in these classes was reused as the deprecation text. 
>> 
>> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build error; add removal annotation.

Looks good, still.

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

PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2750338429

From duke at openjdk.org  Tue Apr  8 15:13:20 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 8 Apr 2025 15:13:20 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v3]
In-Reply-To: <OSc3QmBnvBvNITU3-t-4EYjK09r42aa5T3rvaztKbgI=.d7af7086-1839-42bf-9bd6-18b0d5eda683@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
 <OSc3QmBnvBvNITU3-t-4EYjK09r42aa5T3rvaztKbgI=.d7af7086-1839-42bf-9bd6-18b0d5eda683@github.com>
Message-ID: <24wR6AVIfTd9KtlS4sK_-TAx_A5eEe1-edWjf6CurZk=.84e12340-06c5-4a27-9fb6-c35610e3e4c8@github.com>

On Tue, 8 Apr 2025 14:23:06 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
>> 
>> The current API note in these classes was reused as the deprecation text. 
>> 
>> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build error; add removal annotation.

Marked as reviewed by dmlloyd at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2750361672

From rriggs at openjdk.org  Tue Apr  8 16:09:27 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Apr 2025 16:09:27 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: <fPf4I6lx1VDVOXn0m756xJFfn5xwJ_hjYjzGJvmmdIE=.1b3ac35e-2438-4d6b-9a0b-3f52e2fe17f0@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>
 <fPf4I6lx1VDVOXn0m756xJFfn5xwJ_hjYjzGJvmmdIE=.1b3ac35e-2438-4d6b-9a0b-3f52e2fe17f0@github.com>
Message-ID: <WBqp_kq9JcSAs_SXxuSSsVE6atrT18clBobXK8GRyV0=.508bbd8c-f143-4654-a734-c728b65eee06@github.com>

On Tue, 8 Apr 2025 06:41:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Roger Riggs 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 10 additional commits since the last revision:
>> 
>>  - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
>>    SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
>>  - Merge branch 'master' into 8353641-deprecate-premission-classes
>>  - Missing suppresswarnings
>>  - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
>>    Remove dead code from ForkJoinPool.
>>    Add @SuppressWarnings("remove")
>>  - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
>>  - Update copyright in WindowsFileCopy
>>  - Remove unused import of LinkPermission
>>  - Updated style of @Deprecated to match most existing @Deprecated annotations
>>    `since` comes before `forRemoval`
>>    No spaces around `=`
>>  - Add SuppressWarnings to a Windows source missed earlier.
>>  - 8353641: Deprecate core library permission classes for removal
>>    
>>    Now that the Security Manager is permanently disabled, the following permission classes
>>    in the core libraries area can be deprecated for removal as they are no longer useful:
>>    FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
>>    RuntimePermission, and SerializablePermission
>>    
>>    @Deprecated(forRemoval = true, since="25")
>>    Is added to each class and the existing @apiNote is converted to @deprected
>
> src/java.base/share/classes/jdk/internal/access/JavaIOFilePermissionAccess.java line 49:
> 
>> 47:      */
>> 48:     @SuppressWarnings("removal")
>> 49:     FilePermission newPermUsingAltPath(FilePermission input);
> 
> I assume JavaIOFilePermissionAccess can be removed, nothing should be using this now.

Filed JDK-8354053 to remove as a separate issue.

> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java line 443:
> 
>> 441:     @SuppressWarnings("removal")
>> 442:     private void defineTransletClasses()
>> 443:         throws TransformerConfigurationException {
> 
> In passing, the PermissionCollection used to construct the PD here is no longer needed. If this is cleaned up then the SW wouldn't be needed.

Filed JDK-8354054 to cleanup in a separate issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2033542174
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2033538959

From rriggs at openjdk.org  Tue Apr  8 16:16:23 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Apr 2025 16:16:23 GMT
Subject: RFR: 8348967: Deprecate security permission classes for removal
 [v3]
In-Reply-To: <OSc3QmBnvBvNITU3-t-4EYjK09r42aa5T3rvaztKbgI=.d7af7086-1839-42bf-9bd6-18b0d5eda683@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
 <OSc3QmBnvBvNITU3-t-4EYjK09r42aa5T3rvaztKbgI=.d7af7086-1839-42bf-9bd6-18b0d5eda683@github.com>
Message-ID: <C0NTQ_6QDM3ZovCjCUgVBdKOrqQZWOYBZh0vLbOrvbQ=.89a492ce-080c-40fe-bdd3-dbe0f2fe02eb@github.com>

On Tue, 8 Apr 2025 14:23:06 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
>> 
>> The current API note in these classes was reused as the deprecation text. 
>> 
>> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build error; add removal annotation.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2750589286

From mullan at openjdk.org  Tue Apr  8 16:16:24 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 8 Apr 2025 16:16:24 GMT
Subject: Integrated: 8348967: Deprecate security permission classes for removal
In-Reply-To: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
References: <NfoB-AbMu_Bx3p94ug37wqGcPBfapYNFAuZlouGpdvo=.35daffb5-69cf-4a2c-b2dc-470613406b97@github.com>
Message-ID: <Lmzz0Icv7kJl9h0OGq50UWOYq-ByUfd6ETgJRRIlz-c=.ee0bfa2d-986c-4f42-acda-8a0a686a74e7@github.com>

On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> 
> The current API note in these classes was reused as the deprecation text. 
> 
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680

This pull request has now been integrated.

Changeset: 3cbe686d
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3cbe686d6203043e95604b3d6c96d6ed9d5364c3
Stats:     36 lines in 11 files changed: 20 ins; 0 del; 16 mod

8348967: Deprecate security permission classes for removal

Reviewed-by: rriggs, iris

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

PR: https://git.openjdk.org/jdk/pull/24445

From vyazici at openjdk.org  Tue Apr  8 19:27:17 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 8 Apr 2025 19:27:17 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v12]
In-Reply-To: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
Message-ID: <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>

> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
> 
> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Add `@implNote` to state that the built-in is always non-empty

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24154/files
  - new: https://git.openjdk.org/jdk/pull/24154/files/db61a015..a1bb8cf0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=10-11

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24154/head:pull/24154

PR: https://git.openjdk.org/jdk/pull/24154

From bpb at openjdk.org  Tue Apr  8 22:56:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 8 Apr 2025 22:56:53 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v12]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <KE7Ucy7Riw8XDq2Lqh901Dhw4RwsTY7E3nc18LoCgrY=.727216de-4084-43d3-8437-c9644bc72fbd@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - Merge
 - 8337143: Removed dependency of libjava on headers in libnio/ch
 - ... and 2 more: https://git.openjdk.org/jdk/compare/5b42c46b...3e1e15dc

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=11
  Stats: 1541 lines in 93 files changed: 774 ins; 668 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From michaelm at openjdk.org  Wed Apr  9 09:14:45 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 9 Apr 2025 09:14:45 GMT
Subject: RFR: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8 [v3]
In-Reply-To: <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
 <mz2lBE6ujb0D0_MnnatKB1K-o2dFz0r_1wN8IfyzJwA=.8054444a-2bee-4189-9859-02eff8cd3562@github.com>
Message-ID: <QVE1clUsShwrhq-7r8UY4yg2vhNzvi_1vi2p7ES5nh0=.681be701-0923-4f8e-8691-43af7c5bed72@github.com>

On Fri, 4 Apr 2025 09:13:30 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
>> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
>> 
>> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
>> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
>> 
>> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
>> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

LGTM also.

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

PR Comment: https://git.openjdk.org/jdk/pull/24437#issuecomment-2788908371

From duke at openjdk.org  Wed Apr  9 09:14:46 2025
From: duke at openjdk.org (Daishi Tabata)
Date: Wed, 9 Apr 2025 09:14:46 GMT
Subject: Integrated: 8353698: Output of Simple Web Server is garbled if the
 console's encoding is not UTF-8
In-Reply-To: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
References: <zO79tRNsd98lY0OB0bVBP8ifMTixEUFlifldfqQK5_8=.a2ec4fc3-c87a-4da2-be5e-915c0373c6ca@github.com>
Message-ID: <2_nvIoEa6TVducSL1_YN6E3KK4M19XZUS2TsM3_Pn6Q=.ea9dd99e-ed89-40e0-8dc5-cfd43f1c9608@github.com>

On Fri, 4 Apr 2025 06:22:16 GMT, Daishi Tabata <duke at openjdk.org> wrote:

> The output?`jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. Therefore, if the console encoding is not set to UTF-8 (for example, MS932 on Japanese Windows), garbled characters may appear.?
> Since System.out?knows the console's encoding, there's no need to specify it again with?PrintWriter constructor.
> 
> The output?`jwebserver` and `java -m jdk.httpserver` is localized in Japanese, German, and Chinese. This bug only occurs in these localized languages, so I haven't added any tests.
> I have confirmed that the output of the two commands is not garbled in the default command prompts of both Japanese Windows and English Windows.
> 
> I tested jdk/com/sun/net/httpserver/simpleserver on English Windows, and all tests passed. However, when running on Japanese Windows, some tests failed because they expected output only in English.
> I modified the tests so that `jwebserver` and?`java -m jdk.httpserver`?within the tests are executed with an English locale. After this modification, all tests passed on Japanese Windows.

This pull request has now been integrated.

Changeset: f7fa05f5
Author:    Daishi Tabata <tabata.daishi at fujitsu.com>
Committer: Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7fa05f577a28870202ccaa3544c34b58bd4adfe
Stats:     65 lines in 10 files changed: 9 ins; 3 del; 53 mod

8353698: Output of Simple Web Server is garbled if the console's encoding is not UTF-8

Reviewed-by: djelinski, dfuchs

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

PR: https://git.openjdk.org/jdk/pull/24437

From michaelm at openjdk.org  Wed Apr  9 10:04:47 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 9 Apr 2025 10:04:47 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v4]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <7QqAa8kPfdRpCCwiAleAk7v53UshuArCnUvMpRR0On8=.4646bb5b-5382-437c-9e7e-9e8513698d4a@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - doc + copyright update
 - remove file added by mistake
 - whitespace
 - moved test
 - Merge branch 'master' into 8348986-exceptions
 - update
 - update
 - ... and 7 more: https://git.openjdk.org/jdk/compare/f7fa05f5...f5501d18

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=03
  Stats: 1000 lines in 42 files changed: 767 ins; 104 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From dfuchs at openjdk.org  Wed Apr  9 11:02:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 9 Apr 2025 11:02:36 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v12]
In-Reply-To: <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
Message-ID: <kgNgLeI1gDXMcW5rUbMnM4J7cxdV8qYcjnqoI21ruZs=.105e1a77-a557-444f-b5d8-4cb0e80fa105@github.com>

On Tue, 8 Apr 2025 19:27:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `@implNote` to state that the built-in is always non-empty

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24154#pullrequestreview-2753073405

From vyazici at openjdk.org  Wed Apr  9 11:17:50 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 9 Apr 2025 11:17:50 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost"
Message-ID: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>

Overhauls `EmptyAuthenticate` to

- Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
- Test both clear-text and SSL
- Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems

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

Commit messages:
 - Overhaul `EmptyAuthenticate`

Changes: https://git.openjdk.org/jdk/pull/24542/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352431
  Stats: 121 lines in 1 file changed: 82 ins; 19 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24542/head:pull/24542

PR: https://git.openjdk.org/jdk/pull/24542

From jpai at openjdk.org  Wed Apr  9 11:33:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Apr 2025 11:33:30 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost"
In-Reply-To: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
Message-ID: <YgJgbNxiyXegyuAj9ZyWnF56S8RQZWU1qSKP6vAnDDQ=.a9c29168-147d-4d90-a3d3-b08a706c2137@github.com>

On Wed, 9 Apr 2025 11:12:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Overhauls `EmptyAuthenticate` to
> 
> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
> - Test both clear-text and SSL
> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems

test/jdk/java/net/httpclient/EmptyAuthenticate.java line 83:

> 81:                     responseHeaders.firstValue(WWW_AUTH_HEADER_NAME).orElse(null),
> 82:                     () -> "was expecting empty `%s` header in: %s".formatted(
> 83:                             WWW_AUTH_HEADER_NAME, responseHeaders.map()));

Hello Volkan, this appears to be the opposite of what the original test case was expecting. Before this change, we had:

boolean ok = !response.headers().firstValue("WWW-Authenticate").isEmpty();
if (!ok) {
    throw new RuntimeException("WWW-Authenticate missing");
}

So the test was expecting the response header value to be non-empty unlike this updated version. Did I misread the code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035171076

From jpai at openjdk.org  Wed Apr  9 11:38:35 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Apr 2025 11:38:35 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost"
In-Reply-To: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
Message-ID: <6a48nukqGakIYDx8yGDX2Z1fqfSlZGDlS3A7rP9n0tk=.ee372c53-175f-47f1-a34d-3d0e3ef7cbe8@github.com>

On Wed, 9 Apr 2025 11:12:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Overhauls `EmptyAuthenticate` to
> 
> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
> - Test both clear-text and SSL
> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems

test/jdk/java/net/httpclient/EmptyAuthenticate.java line 74:

> 72:     @MethodSource("args")
> 73:     void test(Version version, boolean secure) throws Exception {
> 74:         HttpTestServer server = createStartedServerRespondingWithEmptyWwwAuthHeader(version, secure);

Nit - in general, I think it should be OK to have simpler names for these methods. So `startServer()` should be fine. Similarly the `ServerHandlerRespondingWithEmptyWwwAuthHeader` handler class could be named just `Handler`. If the method or the class in these tests does something very involved (unlike in this case), I think, the names can still stay simple and a brief code comment on the method/class would be fine.

However, if you prefer it to use the current form, that's fine with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035177810

From dfuchs at openjdk.org  Wed Apr  9 11:38:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 9 Apr 2025 11:38:36 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost"
In-Reply-To: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
Message-ID: <uCvytikRiK0EXc_WyUngW88BKZIPJxk8vk4SMANAKY8=.bfe14421-ffda-41d4-b4a6-8545258014ba@github.com>

On Wed, 9 Apr 2025 11:12:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Overhauls `EmptyAuthenticate` to
> 
> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
> - Test both clear-text and SSL
> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems

test/jdk/java/net/httpclient/EmptyAuthenticate.java line 103:

> 101:                 : HttpTestServer.create(version);
> 102:         HttpTestHandler handler = new ServerHandlerRespondingWithEmptyWwwAuthHeader();
> 103:         server.addHandler(handler, "/");

Suggestion:

        server.addHandler(handler, "/EmptyAuthenticate/");

test/jdk/java/net/httpclient/EmptyAuthenticate.java line 137:

> 135: 
> 136:     private static HttpRequest createRequest(HttpTestServer server, boolean secure) {
> 137:         URI uri = URI.create("%s://%s/".formatted(secure ? "https" : "http", server.serverAuthority()));

Suggestion:

        URI uri = URI.create("%s://%s/EmptyAuthenticate/%s".formatted(secure ? "https" : "http", server.serverAuthority(), server.gerVersion()));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035173678
PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035178194

From jpai at openjdk.org  Wed Apr  9 11:46:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Apr 2025 11:46:30 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost"
In-Reply-To: <YgJgbNxiyXegyuAj9ZyWnF56S8RQZWU1qSKP6vAnDDQ=.a9c29168-147d-4d90-a3d3-b08a706c2137@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <YgJgbNxiyXegyuAj9ZyWnF56S8RQZWU1qSKP6vAnDDQ=.a9c29168-147d-4d90-a3d3-b08a706c2137@github.com>
Message-ID: <kL8uPJiaIEWEwP3qBHT42OBexmqvYBp4pTO5MoZwjwc=.b1ec0a5c-d822-452c-a1e1-5738d0aabe3d@github.com>

On Wed, 9 Apr 2025 11:30:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Overhauls `EmptyAuthenticate` to
>> 
>> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
>> - Test both clear-text and SSL
>> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems
>
> test/jdk/java/net/httpclient/EmptyAuthenticate.java line 83:
> 
>> 81:                     responseHeaders.firstValue(WWW_AUTH_HEADER_NAME).orElse(null),
>> 82:                     () -> "was expecting empty `%s` header in: %s".formatted(
>> 83:                             WWW_AUTH_HEADER_NAME, responseHeaders.map()));
> 
> Hello Volkan, this appears to be the opposite of what the original test case was expecting. Before this change, we had:
> 
> boolean ok = !response.headers().firstValue("WWW-Authenticate").isEmpty();
> if (!ok) {
>     throw new RuntimeException("WWW-Authenticate missing");
> }
> 
> So the test was expecting the response header value to be non-empty unlike this updated version. Did I misread the code?

I'm guessing that this test passes for you locally. If so, then we might need some additional investigation here as to why it passes (given the exact opposite assertion of what the test was previously asserting).

I see that the original test was using lower case response header in the server handler and on the client side the test was reading a upper case response header. In this updated version, we use the upper case header consistently in both the handler and the client. You might want to check the original issue https://bugs.openjdk.org/browse/JDK-8263899 to see if the case of the header was playing a role in this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035189071

From dfuchs at openjdk.org  Wed Apr  9 12:09:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 9 Apr 2025 12:09:31 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost"
In-Reply-To: <kL8uPJiaIEWEwP3qBHT42OBexmqvYBp4pTO5MoZwjwc=.b1ec0a5c-d822-452c-a1e1-5738d0aabe3d@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <YgJgbNxiyXegyuAj9ZyWnF56S8RQZWU1qSKP6vAnDDQ=.a9c29168-147d-4d90-a3d3-b08a706c2137@github.com>
 <kL8uPJiaIEWEwP3qBHT42OBexmqvYBp4pTO5MoZwjwc=.b1ec0a5c-d822-452c-a1e1-5738d0aabe3d@github.com>
Message-ID: <tzEC3JiLHM07uOhumu9eKIjLHU46MFFvrIkuvh1EHZc=.ef765413-8697-4aba-8d66-829dc34bc3ca@github.com>

On Wed, 9 Apr 2025 11:43:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/EmptyAuthenticate.java line 83:
>> 
>>> 81:                     responseHeaders.firstValue(WWW_AUTH_HEADER_NAME).orElse(null),
>>> 82:                     () -> "was expecting empty `%s` header in: %s".formatted(
>>> 83:                             WWW_AUTH_HEADER_NAME, responseHeaders.map()));
>> 
>> Hello Volkan, this appears to be the opposite of what the original test case was expecting. Before this change, we had:
>> 
>> boolean ok = !response.headers().firstValue("WWW-Authenticate").isEmpty();
>> if (!ok) {
>>     throw new RuntimeException("WWW-Authenticate missing");
>> }
>> 
>> So the test was expecting the response header value to be non-empty unlike this updated version. Did I misread the code?
>
> I'm guessing that this test passes for you locally. If so, then we might need some additional investigation here as to why it passes (given the exact opposite assertion of what the test was previously asserting).
> 
> I see that the original test was using lower case response header in the server handler and on the client side the test was reading a upper case response header. In this updated version, we use the upper case header consistently in both the handler and the client. You might want to check the original issue https://bugs.openjdk.org/browse/JDK-8263899 to see if the case of the header was playing a role in this test.

firstValue(name) returns an Optional, so we were just testing that the Optional was not empty :-).
Now we're additionally checking that the value is the empty string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035226225

From jpai at openjdk.org  Wed Apr  9 12:18:41 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Apr 2025 12:18:41 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost"
In-Reply-To: <tzEC3JiLHM07uOhumu9eKIjLHU46MFFvrIkuvh1EHZc=.ef765413-8697-4aba-8d66-829dc34bc3ca@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <YgJgbNxiyXegyuAj9ZyWnF56S8RQZWU1qSKP6vAnDDQ=.a9c29168-147d-4d90-a3d3-b08a706c2137@github.com>
 <kL8uPJiaIEWEwP3qBHT42OBexmqvYBp4pTO5MoZwjwc=.b1ec0a5c-d822-452c-a1e1-5738d0aabe3d@github.com>
 <tzEC3JiLHM07uOhumu9eKIjLHU46MFFvrIkuvh1EHZc=.ef765413-8697-4aba-8d66-829dc34bc3ca@github.com>
Message-ID: <oF_nD_LdYyPfOmY8I9C_ybQIU_0mCqfS_5ABTL6DcWg=.94948270-4a68-4e5b-8c7b-b6aacd3b14b6@github.com>

On Wed, 9 Apr 2025 12:06:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I'm guessing that this test passes for you locally. If so, then we might need some additional investigation here as to why it passes (given the exact opposite assertion of what the test was previously asserting).
>> 
>> I see that the original test was using lower case response header in the server handler and on the client side the test was reading a upper case response header. In this updated version, we use the upper case header consistently in both the handler and the client. You might want to check the original issue https://bugs.openjdk.org/browse/JDK-8263899 to see if the case of the header was playing a role in this test.
>
> firstValue(name) returns an Optional, so we were just testing that the Optional was not empty :-).
> Now we're additionally checking that the value is the empty string.

That explains it :) The method chaining and the same name `isEmpty()` in the original test didn't help me notice that it was checking an `Optional`. Thank you Daniel.

What Volkan has in the updated version looks fine then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035241063

From vyazici at openjdk.org  Wed Apr  9 13:36:23 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 9 Apr 2025 13:36:23 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v2]
In-Reply-To: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
Message-ID: <evpZkVwYcdL-5sEfT9ei9cIYk4X3juE4JGIjc4yVz8Y=.0d6ca52d-73e9-42e6-85d0-78b1ab818caa@github.com>

> Overhauls `EmptyAuthenticate` to
> 
> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
> - Test both clear-text and SSL
> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Apply review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24542/files
  - new: https://git.openjdk.org/jdk/pull/24542/files/4c6f542e..7b5c8490

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24542&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24542&range=00-01

  Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24542/head:pull/24542

PR: https://git.openjdk.org/jdk/pull/24542

From vyazici at openjdk.org  Wed Apr  9 13:36:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 9 Apr 2025 13:36:26 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v2]
In-Reply-To: <6a48nukqGakIYDx8yGDX2Z1fqfSlZGDlS3A7rP9n0tk=.ee372c53-175f-47f1-a34d-3d0e3ef7cbe8@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <6a48nukqGakIYDx8yGDX2Z1fqfSlZGDlS3A7rP9n0tk=.ee372c53-175f-47f1-a34d-3d0e3ef7cbe8@github.com>
Message-ID: <jf32qNwojnWXUzHOFdZWhKOutCxQmDwgtjzdRR_zut0=.626aeff3-efdc-4827-a127-a1a750568c96@github.com>

On Wed, 9 Apr 2025 11:35:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review suggestions
>
> test/jdk/java/net/httpclient/EmptyAuthenticate.java line 74:
> 
>> 72:     @MethodSource("args")
>> 73:     void test(Version version, boolean secure) throws Exception {
>> 74:         HttpTestServer server = createStartedServerRespondingWithEmptyWwwAuthHeader(version, secure);
> 
> Nit - in general, I think it should be OK to have simpler names for these methods. So `startServer()` should be fine. Similarly the `ServerHandlerRespondingWithEmptyWwwAuthHeader` handler class could be named just `Handler`. If the method or the class in these tests does something very involved (unlike in this case), I think, the names can still stay simple and a brief code comment on the method/class would be fine.
> 
> However, if you prefer it to use the current form, that's fine with me.

Shortened in 7b5c849002c2302a3b4d4cdec3fd427fc9a1c4f7.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035387247

From vyazici at openjdk.org  Wed Apr  9 13:36:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 9 Apr 2025 13:36:27 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v2]
In-Reply-To: <uCvytikRiK0EXc_WyUngW88BKZIPJxk8vk4SMANAKY8=.bfe14421-ffda-41d4-b4a6-8545258014ba@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <uCvytikRiK0EXc_WyUngW88BKZIPJxk8vk4SMANAKY8=.bfe14421-ffda-41d4-b4a6-8545258014ba@github.com>
Message-ID: <5Ka4tTThT52UZCTSlXwecGK4KGuO5hC9BdM6ryYScOo=.454d93d6-7191-4e4b-bfc6-e1223c8ed727@github.com>

On Wed, 9 Apr 2025 11:32:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review suggestions
>
> test/jdk/java/net/httpclient/EmptyAuthenticate.java line 103:
> 
>> 101:                 : HttpTestServer.create(version);
>> 102:         HttpTestHandler handler = new ServerHandlerRespondingWithEmptyWwwAuthHeader();
>> 103:         server.addHandler(handler, "/");
> 
> Suggestion:
> 
>         server.addHandler(handler, "/EmptyAuthenticate/");

Applied it in 7b5c849002c2302a3b4d4cdec3fd427fc9a1c4f7.

> test/jdk/java/net/httpclient/EmptyAuthenticate.java line 137:
> 
>> 135: 
>> 136:     private static HttpRequest createRequest(HttpTestServer server, boolean secure) {
>> 137:         URI uri = URI.create("%s://%s/".formatted(secure ? "https" : "http", server.serverAuthority()));
> 
> Suggestion:
> 
>         URI uri = URI.create("%s://%s/EmptyAuthenticate/%s".formatted(secure ? "https" : "http", server.serverAuthority(), server.gerVersion()));

Applied it in 7b5c849002c2302a3b4d4cdec3fd427fc9a1c4f7.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035387734
PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035388038

From jpai at openjdk.org  Wed Apr  9 13:46:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Apr 2025 13:46:26 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v2]
In-Reply-To: <evpZkVwYcdL-5sEfT9ei9cIYk4X3juE4JGIjc4yVz8Y=.0d6ca52d-73e9-42e6-85d0-78b1ab818caa@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <evpZkVwYcdL-5sEfT9ei9cIYk4X3juE4JGIjc4yVz8Y=.0d6ca52d-73e9-42e6-85d0-78b1ab818caa@github.com>
Message-ID: <A_tP7IEQyIK4FPUHVt5fWiL0GE6jXIRKmpLISQzoaiM=.287ab077-c119-4e50-af1d-3182ba36e675@github.com>

On Wed, 9 Apr 2025 13:36:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Overhauls `EmptyAuthenticate` to
>> 
>> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
>> - Test both clear-text and SSL
>> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review suggestions

Thank you for the updates. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24542#pullrequestreview-2753544836

From michaelm at openjdk.org  Wed Apr  9 14:14:50 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 9 Apr 2025 14:14:50 GMT
Subject: RFR: 8285888: Clarify that java.net.http.HttpClient do NOT support
 Digest authentication
Message-ID: <6MVPnINp7uqeWzO6kU7kcy6b9pwnIaHxMmxM6jp8mzg=.48fb20d6-556f-4269-9a40-644ae2817c8c@github.com>

Hi,

This is a minor doc change to clarify that java.net.http.HttpClient only supports HTTP Basic authentication.

Thanks,
Michael

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

Commit messages:
 - update

Changes: https://git.openjdk.org/jdk/pull/24550/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24550&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285888
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24550/head:pull/24550

PR: https://git.openjdk.org/jdk/pull/24550

From dfuchs at openjdk.org  Wed Apr  9 14:21:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 9 Apr 2025 14:21:28 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v2]
In-Reply-To: <evpZkVwYcdL-5sEfT9ei9cIYk4X3juE4JGIjc4yVz8Y=.0d6ca52d-73e9-42e6-85d0-78b1ab818caa@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <evpZkVwYcdL-5sEfT9ei9cIYk4X3juE4JGIjc4yVz8Y=.0d6ca52d-73e9-42e6-85d0-78b1ab818caa@github.com>
Message-ID: <H3bfdbmvlrqoT4JURerBrwDX-DMjlnHrDhFOU36jV7w=.a24a24d2-fc1e-444d-bef8-47f6cbed19c6@github.com>

On Wed, 9 Apr 2025 13:36:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Overhauls `EmptyAuthenticate` to
>> 
>> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
>> - Test both clear-text and SSL
>> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review suggestions

test/jdk/java/net/httpclient/EmptyAuthenticate.java line 75:

> 73:     void test(Version version, boolean secure) throws Exception {
> 74:         String uriPath = "/%s/%s/%s".formatted(EmptyAuthenticate.class.getSimpleName(), version, secure ? 's' : 'c');
> 75:         HttpTestServer server = createServer(version, secure, uriPath);

It's  actually better practice to have uri looks like "/rootpath/morechars" and register the handler for "/rootpath/"
=> make sure the path you pass to addHandler ends with "/". 

Suggestion:

        String handlerPath = "/%s/%s/".formatted(EmptyAuthenticate.class.getSimpleName(), version)
        String uriPath = handlerPath + (secure ? 's' : 'c');
        HttpTestServer server = createServer(version, secure, handlerPath);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035482362

From dfuchs at openjdk.org  Wed Apr  9 14:24:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 9 Apr 2025 14:24:36 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v2]
In-Reply-To: <H3bfdbmvlrqoT4JURerBrwDX-DMjlnHrDhFOU36jV7w=.a24a24d2-fc1e-444d-bef8-47f6cbed19c6@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <evpZkVwYcdL-5sEfT9ei9cIYk4X3juE4JGIjc4yVz8Y=.0d6ca52d-73e9-42e6-85d0-78b1ab818caa@github.com>
 <H3bfdbmvlrqoT4JURerBrwDX-DMjlnHrDhFOU36jV7w=.a24a24d2-fc1e-444d-bef8-47f6cbed19c6@github.com>
Message-ID: <K1D7I75CE5LDLmsgge-TJLJV8sso8hQ97ltcGm-hFyk=.9272f1b6-850f-471b-ae15-311062ca46b7@github.com>

On Wed, 9 Apr 2025 14:18:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review suggestions
>
> test/jdk/java/net/httpclient/EmptyAuthenticate.java line 75:
> 
>> 73:     void test(Version version, boolean secure) throws Exception {
>> 74:         String uriPath = "/%s/%s/%s".formatted(EmptyAuthenticate.class.getSimpleName(), version, secure ? 's' : 'c');
>> 75:         HttpTestServer server = createServer(version, secure, uriPath);
> 
> It's  actually better practice to have uri looks like "/rootpath/morechars" and register the handler for "/rootpath/"
> => make sure the path you pass to addHandler ends with "/". 
> 
> Suggestion:
> 
>         String handlerPath = "/%s/%s/".formatted(EmptyAuthenticate.class.getSimpleName(), version)
>         String uriPath = handlerPath + (secure ? 's' : 'c');
>         HttpTestServer server = createServer(version, secure, handlerPath);

Rationale:   if you add a handler for "/foo" it will match "/foo/x" but also "/foobar" which is not always expected by the developper. The recommendation is therefore to use "/foo/" instead of "/foo" if you don't want "/foobar" to be matched.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035489732

From jpai at openjdk.org  Wed Apr  9 14:34:33 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Apr 2025 14:34:33 GMT
Subject: RFR: 8285888: Clarify that java.net.http.HttpClient do NOT support
 Digest authentication
In-Reply-To: <6MVPnINp7uqeWzO6kU7kcy6b9pwnIaHxMmxM6jp8mzg=.48fb20d6-556f-4269-9a40-644ae2817c8c@github.com>
References: <6MVPnINp7uqeWzO6kU7kcy6b9pwnIaHxMmxM6jp8mzg=.48fb20d6-556f-4269-9a40-644ae2817c8c@github.com>
Message-ID: <VAGvuiTcd59Z7liBQ3Q4kamwfSLyP8VlJty63ESmhfU=.399be294-b2d9-434e-a094-53e5bbd878e3@github.com>

On Wed, 9 Apr 2025 14:08:06 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a minor doc change to clarify that java.net.http.HttpClient only supports HTTP Basic authentication.
> 
> Thanks,
> Michael

The change looks good to me.

The copyright year on the file will need an update before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24550#pullrequestreview-2753715569

From vyazici at openjdk.org  Wed Apr  9 14:35:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 9 Apr 2025 14:35:30 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v3]
In-Reply-To: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
Message-ID: <HozgOd3LVvIEtU57oOnJA5CCgFe2Qd5kDRU0H12ZJJ8=.895d6ca1-9def-4cf9-8f2d-df2b485cfa33@github.com>

> Overhauls `EmptyAuthenticate` to
> 
> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
> - Test both clear-text and SSL
> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Improve handler path
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24542/files
  - new: https://git.openjdk.org/jdk/pull/24542/files/7b5c8490..f175efe5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24542&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24542&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24542/head:pull/24542

PR: https://git.openjdk.org/jdk/pull/24542

From vyazici at openjdk.org  Wed Apr  9 14:35:31 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 9 Apr 2025 14:35:31 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v2]
In-Reply-To: <K1D7I75CE5LDLmsgge-TJLJV8sso8hQ97ltcGm-hFyk=.9272f1b6-850f-471b-ae15-311062ca46b7@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <evpZkVwYcdL-5sEfT9ei9cIYk4X3juE4JGIjc4yVz8Y=.0d6ca52d-73e9-42e6-85d0-78b1ab818caa@github.com>
 <H3bfdbmvlrqoT4JURerBrwDX-DMjlnHrDhFOU36jV7w=.a24a24d2-fc1e-444d-bef8-47f6cbed19c6@github.com>
 <K1D7I75CE5LDLmsgge-TJLJV8sso8hQ97ltcGm-hFyk=.9272f1b6-850f-471b-ae15-311062ca46b7@github.com>
Message-ID: <zxhzCZRCzYce_i7b2w1IwoWLHjoGOMr5PLBwG_6I61w=.27a7b85e-61e0-4e59-8faf-aa5da7d92105@github.com>

On Wed, 9 Apr 2025 14:21:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/EmptyAuthenticate.java line 75:
>> 
>>> 73:     void test(Version version, boolean secure) throws Exception {
>>> 74:         String uriPath = "/%s/%s/%s".formatted(EmptyAuthenticate.class.getSimpleName(), version, secure ? 's' : 'c');
>>> 75:         HttpTestServer server = createServer(version, secure, uriPath);
>> 
>> It's  actually better practice to have uri looks like "/rootpath/morechars" and register the handler for "/rootpath/"
>> => make sure the path you pass to addHandler ends with "/". 
>> 
>> Suggestion:
>> 
>>         String handlerPath = "/%s/%s/".formatted(EmptyAuthenticate.class.getSimpleName(), version)
>>         String uriPath = handlerPath + (secure ? 's' : 'c');
>>         HttpTestServer server = createServer(version, secure, handlerPath);
>
> Rationale:   if you add a handler for "/foo" it will match "/foo/x" but also "/foobar" which is not always expected by the developper. The recommendation is therefore to use "/foo/" instead of "/foo" if you don't want "/foobar" to be matched.

@dfuch, thanks so much for keeping an eye on this and the clarification. I had thought the difference in request and handler paths in your initial suggestion was an oversight, not something intentional.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035509851

From dfuchs at openjdk.org  Wed Apr  9 14:50:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 9 Apr 2025 14:50:32 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v3]
In-Reply-To: <HozgOd3LVvIEtU57oOnJA5CCgFe2Qd5kDRU0H12ZJJ8=.895d6ca1-9def-4cf9-8f2d-df2b485cfa33@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <HozgOd3LVvIEtU57oOnJA5CCgFe2Qd5kDRU0H12ZJJ8=.895d6ca1-9def-4cf9-8f2d-df2b485cfa33@github.com>
Message-ID: <8sgGTqj_A9DM4Wznx2Wi4J1wHFk3X4lQOTl1UsGaFuA=.7c929978-28f0-4354-8b79-7c8a6dea72ad@github.com>

On Wed, 9 Apr 2025 14:35:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Overhauls `EmptyAuthenticate` to
>> 
>> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
>> - Test both clear-text and SSL
>> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve handler path
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

test/jdk/java/net/httpclient/EmptyAuthenticate.java line 74:

> 72:     @MethodSource("args")
> 73:     void test(Version version, boolean secure) throws Exception {
> 74:         String handlerPath = "/%s/%s/".formatted(EmptyAuthenticate.class.getSimpleName(), version)

(D'oh)
Suggestion:

        String handlerPath = "/%s/%s/".formatted(EmptyAuthenticate.class.getSimpleName(), version);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24542#discussion_r2035545174

From ihse at openjdk.org  Wed Apr  9 15:09:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 15:09:58 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:

> 20: # Peter Smolik
> 21: Cp1250 WINDOWS-1250 0x00FF
> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)

This does not seem to have been a correct conversion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2035582242

From jlu at openjdk.org  Wed Apr  9 21:28:41 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Apr 2025 21:28:41 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
Message-ID: <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>

On Wed, 9 Apr 2025 15:06:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Convert the merged master changes to UTF-8
>>  - Merge master and fix conflicts
>>  - Close streams when finished loading into props
>>  - Adjust CF test to read in with UTF-8 to fix failing test
>>  - Reconvert CS.properties to UTF-8
>>  - Revert all changes to CurrencySymbols.properties
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a
>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
> 
>> 20: # Peter Smolik
>> 21: Cp1250 WINDOWS-1250 0x00FF
>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
> 
> This does not seem to have been a correct conversion.

Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)

Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036165417

From vyazici at openjdk.org  Thu Apr 10 05:52:07 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Apr 2025 05:52:07 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v4]
In-Reply-To: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
Message-ID: <8kNN5bQJ9fOlV6Ph2UwlsVHRxWKsNuy1JsNlcvw_ZDA=.d50792d9-24e6-4cda-809e-78b2ef54a2c5@github.com>

> Overhauls `EmptyAuthenticate` to
> 
> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
> - Test both clear-text and SSL
> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Fix code typo
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24542/files
  - new: https://git.openjdk.org/jdk/pull/24542/files/f175efe5..ad9391d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24542&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24542&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24542/head:pull/24542

PR: https://git.openjdk.org/jdk/pull/24542

From vyazici at openjdk.org  Thu Apr 10 05:52:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Apr 2025 05:52:26 GMT
Subject: RFR: 8353949: HttpHeaders.firstValueAsLong unnecessarily boxes to Long
Message-ID: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>

Avoid unnecessary boxing in `HttpHeaders::firstValueAsLong`.

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

Commit messages:
 - Avoid unnecessary boxing in `HttpHeaders::firstValueAsLong`

Changes: https://git.openjdk.org/jdk/pull/24561/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24561&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353949
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24561.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24561/head:pull/24561

PR: https://git.openjdk.org/jdk/pull/24561

From ihse at openjdk.org  Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
Message-ID: <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>

On Wed, 9 Apr 2025 21:26:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
>> 
>>> 20: # Peter Smolik
>>> 21: Cp1250 WINDOWS-1250 0x00FF
>>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
>> 
>> This does not seem to have been a correct conversion.
>
> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
> 
> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.

You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036695622

From ihse at openjdk.org  Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
 <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
Message-ID: <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>

On Thu, 10 Apr 2025 07:31:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
>> 
>> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.
>
> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.

If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036696723

From eirbjo at openjdk.org  Thu Apr 10 08:10:42 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:10:42 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
 <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
 <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
Message-ID: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>

On Thu, 10 Apr 2025 07:32:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.
>
> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.

Some observations: 

1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?

2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.

3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`

4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:


byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
String decoded = new String(origBytes, StandardCharsets.UTF_8);
byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
String hex = HexFormat.of().formatHex(encoded);
assertEquals("efbfbd", hex);
``` 

Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036767319

From duke at openjdk.org  Thu Apr 10 08:30:30 2025
From: duke at openjdk.org (serhiysachkov)
Date: Thu, 10 Apr 2025 08:30:30 GMT
Subject: Integrated: 8353847: Remove extra args to System.out.printf in
 open/test/jdk/java/net/httpclient tests
In-Reply-To: <VyexoBS2cXP_Gk9p9IKeuoH-RXgnVCm06F7RX0O2iaM=.d97692bc-3479-43e2-878b-e84f972fac45@github.com>
References: <VyexoBS2cXP_Gk9p9IKeuoH-RXgnVCm06F7RX0O2iaM=.d97692bc-3479-43e2-878b-e84f972fac45@github.com>
Message-ID: <F144cCm-Ym3boOGkPrHGbqjIT41Sb25eHiLD9IxYX5M=.4ee27d1c-9bdb-40c6-9f53-753e88dde7db@github.com>

On Tue, 8 Apr 2025 12:33:52 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Remove extra args to System.out.printf in open/test/jsk/java/net/httpclient tests

This pull request has now been integrated.

Changeset: f94a4f7a
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: Mahendra Chhipa <mchhipa at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f94a4f7accd11161912ec2cdae6e290d0957666a
Stats:     10 lines in 3 files changed: 0 ins; 0 del; 10 mod

8353847: Remove extra args to System.out.printf in open/test/jdk/java/net/httpclient tests

Reviewed-by: dfuchs

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

PR: https://git.openjdk.org/jdk/pull/24507

From ihse at openjdk.org  Thu Apr 10 08:38:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:38:38 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
 <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
 <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
 <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
Message-ID: <qG3Fpev16BBWYvs2zSE5CeqmTcfRF4h_l-PAM3PVHns=.4a1e25de-c3e2-4876-a8e5-c3f32cfef4c1@github.com>

On Thu, 10 Apr 2025 08:08:02 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.
>
> Some observations: 
> 
> 1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?
> 
> 2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.
> 
> 3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`
> 
> 4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:
> 
> 
> byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
> String decoded = new String(origBytes, StandardCharsets.UTF_8);
> byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
> String hex = HexFormat.of().formatHex(encoded);
> assertEquals("efbfbd", hex);
> ``` 
> 
> Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.

> This PR seems to have been abondoned, so perhaps this discussion belongs in https://github.com/openjdk/jdk/pull/15694 ?

Oh, I didn't notice this was supplanted by another PR. It might be better to continue there, yes. Even if closed PRs seldom are the best places to conduct discussions, I think it might be a good idea to scrutinize all files modified by this script.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036820765

From ihse at openjdk.org  Thu Apr 10 08:41:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:41:45 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <yO1q1NVjOInbzcWCkJra3sYGkfv3OBhg__dKO0w--s0=.d7a4b185-6ed1-4ae6-bdfe-01b3204da46a@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Continuing the discussion that was started at a predecessor to this PR, https://github.com/openjdk/jdk/pull/12726#discussion_r2035582242. At least one incorrect conversion has been found in this PR. It might be worthwhile to double- and triple-check all the other conversions as well.

As part of https://bugs.openjdk.org/browse/JDK-8301971 I am trying various ways of detecting files without UTF-8 encoding, but it is still a bit of hit and miss, since there are no surefire way of telling which encoding a file has, only heuristics. So finding and following up potential sources of error is important.

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791991649
PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791997157

From eirbjo at openjdk.org  Thu Apr 10 08:48:37 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:48:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

FWIW, I checked out the revision of the commit previous to this change and found the following:


% git checkout b55e418a077791b39992042411cde97f68dc39fe^ 
% find src -name "*.properties" | xargs file | grep -v ASCII
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: 
  ISO-8859 text
src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
  Unicode text, UTF-8 text, with very long lines (322)


Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792014164

From ihse at openjdk.org  Thu Apr 10 09:45:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 09:45:56 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <GlAmyjF3ZmTQHUhkTXRmmrijCWM_4JoredRJOuyVyIc=.775fbc8d-80da-4b0b-b2e1-e5b7e75b3d52@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Thanks for checking!

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792170460

From dfuchs at openjdk.org  Thu Apr 10 10:11:24 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Apr 2025 10:11:24 GMT
Subject: RFR: 8353949: HttpHeaders.firstValueAsLong unnecessarily boxes to
 Long
In-Reply-To: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>
References: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>
Message-ID: <XAp2OuV6Wyqh2YNdlkmha-Avr_dUqqDBXb-ULotTDJQ=.b31594a1-680f-4794-a24d-db3a09208302@github.com>

On Thu, 10 Apr 2025 05:47:09 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Avoid unnecessary boxing in `HttpHeaders::firstValueAsLong`.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24561#pullrequestreview-2756129194

From dfuchs at openjdk.org  Thu Apr 10 10:11:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Apr 2025 10:11:32 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v4]
In-Reply-To: <8kNN5bQJ9fOlV6Ph2UwlsVHRxWKsNuy1JsNlcvw_ZDA=.d50792d9-24e6-4cda-809e-78b2ef54a2c5@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <8kNN5bQJ9fOlV6Ph2UwlsVHRxWKsNuy1JsNlcvw_ZDA=.d50792d9-24e6-4cda-809e-78b2ef54a2c5@github.com>
Message-ID: <qUFNUxDHRuc_3jMFLY753YcrQCtkKPiRoSvRLKm-8IU=.8023f228-ec56-4f0a-9103-6eccae45d070@github.com>

On Thu, 10 Apr 2025 05:52:07 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Overhauls `EmptyAuthenticate` to
>> 
>> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
>> - Test both clear-text and SSL
>> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix code typo
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24542#pullrequestreview-2756123761

From duke at openjdk.org  Thu Apr 10 10:11:32 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Apr 2025 10:11:32 GMT
Subject: RFR: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost" [v4]
In-Reply-To: <8kNN5bQJ9fOlV6Ph2UwlsVHRxWKsNuy1JsNlcvw_ZDA=.d50792d9-24e6-4cda-809e-78b2ef54a2c5@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
 <8kNN5bQJ9fOlV6Ph2UwlsVHRxWKsNuy1JsNlcvw_ZDA=.d50792d9-24e6-4cda-809e-78b2ef54a2c5@github.com>
Message-ID: <MaNze0r9NUDl3pveP2MBx_aRCxwcX6GnzzrbUsSmoGA=.0b038e09-9a93-4881-a04e-bf1e1aaf3628@github.com>

On Thu, 10 Apr 2025 05:52:07 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Overhauls `EmptyAuthenticate` to
>> 
>> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
>> - Test both clear-text and SSL
>> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix code typo
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

@vy 
Your change (at version ad9391d5decbca689850bfa3785154618aedd0ef) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24542#issuecomment-2792240544

From vyazici at openjdk.org  Thu Apr 10 10:21:37 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Apr 2025 10:21:37 GMT
Subject: Integrated: 8352431: java/net/httpclient/EmptyAuthenticate.java uses
 "localhost"
In-Reply-To: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
References: <rLapjMQ2wdLDMH56J_M5dQBvYqajeDzPPzIEiNW42_Q=.e6ea284d-0359-4be9-9db8-c8a32d173748@github.com>
Message-ID: <rHmvoDVpG5Ji_ExsmGsN0T0XLM3WKQ0oF0ycOCOHhro=.5005dfa1-ac15-4561-ba56-ead32e3b6235@github.com>

On Wed, 9 Apr 2025 11:12:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Overhauls `EmptyAuthenticate` to
> 
> - Test all supported HTTP versions (i.e., HTTP/1.1 and HTTP/2)
> - Test both clear-text and SSL
> - Use `HttpServerAdapters.HttpTestServer::create` to avoid host-related problems

This pull request has now been integrated.

Changeset: 51b3d6bb
Author:    Volkan Yazici <vyazici at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51b3d6bba29b256616cf00c0be7a7fe0f97621ab
Stats:     124 lines in 1 file changed: 84 ins; 19 del; 21 mod

8352431: java/net/httpclient/EmptyAuthenticate.java uses "localhost"

Reviewed-by: dfuchs, jpai

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

PR: https://git.openjdk.org/jdk/pull/24542

From vyazici at openjdk.org  Thu Apr 10 10:44:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Apr 2025 10:44:44 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider
 with thread-safe close semantics
Message-ID: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>

`ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.

### Testing

Changes can be tested as follows:


make build-microbenchmark
build/linux-x64/jdk/bin/java \
  -jar build/linux-x64/images/test/micro/benchmarks.jar \
  -f 1 -wi 1 -i 1 -t 2 \
  "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"


### Background

A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:

- `bind()` can fail, if the file is already created by another thread
- the clean-up of the socket file can fail, if the file is already deleted
  - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
  - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
- the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
  - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)

This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
- using a dedicated (temporary and unique) parent folder for the socket
- encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`

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

Commit messages:
 - 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics

Changes: https://git.openjdk.org/jdk/pull/24568/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24568&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354024
  Stats: 138 lines in 3 files changed: 75 ins; 37 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/24568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24568/head:pull/24568

PR: https://git.openjdk.org/jdk/pull/24568

From duke at openjdk.org  Thu Apr 10 10:48:31 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Apr 2025 10:48:31 GMT
Subject: RFR: 8353949: HttpHeaders.firstValueAsLong unnecessarily boxes to
 Long
In-Reply-To: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>
References: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>
Message-ID: <K3T3NPryPftv8L4UJAOq5xEf-Mjt7am3cWbsv6h92bM=.fa90dc37-d1fc-4171-9e44-dd102fb35418@github.com>

On Thu, 10 Apr 2025 05:47:09 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Avoid unnecessary boxing in `HttpHeaders::firstValueAsLong`.

@vy 
Your change (at version 4385b04466227cacdc9d58e9f6cd1f55968b0e27) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24561#issuecomment-2792331398

From djelinski at openjdk.org  Thu Apr 10 10:51:32 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 10 Apr 2025 10:51:32 GMT
Subject: RFR: 8353949: HttpHeaders.firstValueAsLong unnecessarily boxes to
 Long
In-Reply-To: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>
References: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>
Message-ID: <AOvDCsExJp3_oLniygwCn5A5ad5KaTyd7NAUgz9MowU=.cfc871dc-7140-4637-b07d-0d38c57c92bf@github.com>

On Thu, 10 Apr 2025 05:47:09 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Avoid unnecessary boxing in `HttpHeaders::firstValueAsLong`.

LGTM.

Don't use `noreg-self` for this. That label is used for fixing test issues. `noreg-perf` or `noreg-cleanup` would be more appropriate here.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24561#pullrequestreview-2756233332

From vyazici at openjdk.org  Thu Apr 10 10:58:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Apr 2025 10:58:29 GMT
Subject: RFR: 8353949: HttpHeaders.firstValueAsLong unnecessarily boxes to
 Long
In-Reply-To: <AOvDCsExJp3_oLniygwCn5A5ad5KaTyd7NAUgz9MowU=.cfc871dc-7140-4637-b07d-0d38c57c92bf@github.com>
References: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>
 <AOvDCsExJp3_oLniygwCn5A5ad5KaTyd7NAUgz9MowU=.cfc871dc-7140-4637-b07d-0d38c57c92bf@github.com>
Message-ID: <EVtjC27zHj04DuPu6U8UZDXczwEc63U4nOxIfJ70XoM=.d6071f4a-3a4d-4126-9220-683309ce3e90@github.com>

On Thu, 10 Apr 2025 10:49:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Avoid unnecessary boxing in `HttpHeaders::firstValueAsLong`.
>
> LGTM.
> 
> Don't use `noreg-self` for this. That label is used for fixing test issues. `noreg-perf` or `noreg-cleanup` would be more appropriate here.

@djelinski, thanks for the correction. Updated the ticket accordingly: `s/noreg-self/noreg-perf/`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24561#issuecomment-2792355689

From michaelm at openjdk.org  Thu Apr 10 11:23:57 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 10 Apr 2025 11:23:57 GMT
Subject: RFR: 8285888: Clarify that java.net.http.HttpClient do NOT support
 Digest authentication [v2]
In-Reply-To: <6MVPnINp7uqeWzO6kU7kcy6b9pwnIaHxMmxM6jp8mzg=.48fb20d6-556f-4269-9a40-644ae2817c8c@github.com>
References: <6MVPnINp7uqeWzO6kU7kcy6b9pwnIaHxMmxM6jp8mzg=.48fb20d6-556f-4269-9a40-644ae2817c8c@github.com>
Message-ID: <ifZsI1jsvf71Twme2hV32NVqt-Xit9kXRQsqpE_T-tM=.b5e2c96e-fcdf-4824-93bd-4dd062ebb511@github.com>

> Hi,
> 
> This is a minor doc change to clarify that java.net.http.HttpClient only supports HTTP Basic authentication.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24550/files
  - new: https://git.openjdk.org/jdk/pull/24550/files/f4f78281..a590637a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24550&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24550&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24550/head:pull/24550

PR: https://git.openjdk.org/jdk/pull/24550

From michaelm at openjdk.org  Thu Apr 10 11:34:31 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 10 Apr 2025 11:34:31 GMT
Subject: RFR: 8353949: HttpHeaders.firstValueAsLong unnecessarily boxes to
 Long
In-Reply-To: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>
References: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>
Message-ID: <-Tvd20rK1nyE84pBmg2hEKJZa-z61F5OPO_V0S7x2EI=.20fb3598-f5e6-4d3d-9a65-1d94c4a72e3a@github.com>

On Thu, 10 Apr 2025 05:47:09 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Avoid unnecessary boxing in `HttpHeaders::firstValueAsLong`.

Marked as reviewed by michaelm (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24561#pullrequestreview-2756348007

From djelinski at openjdk.org  Thu Apr 10 11:44:05 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 10 Apr 2025 11:44:05 GMT
Subject: RFR: 8354276: Strict HTTP header validation
Message-ID: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>

RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.

This PR adds the following validation:
- pseudo-headers defined for requests are rejected in responses and push streams
- pseudo-headers defined for responses are rejected in push promises
- connection headers are rejected in responses and push streams

Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.

An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.

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

Commit messages:
 - Fix whitespace problems
 - Do not catch assertion errors
 - More strict header validation

Changes: https://git.openjdk.org/jdk/pull/24569/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354276
  Stats: 70 lines in 5 files changed: 55 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24569/head:pull/24569

PR: https://git.openjdk.org/jdk/pull/24569

From jpai at openjdk.org  Thu Apr 10 12:19:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 10 Apr 2025 12:19:31 GMT
Subject: RFR: 8285888: Clarify that java.net.http.HttpClient do NOT support
 Digest authentication [v2]
In-Reply-To: <ifZsI1jsvf71Twme2hV32NVqt-Xit9kXRQsqpE_T-tM=.b5e2c96e-fcdf-4824-93bd-4dd062ebb511@github.com>
References: <6MVPnINp7uqeWzO6kU7kcy6b9pwnIaHxMmxM6jp8mzg=.48fb20d6-556f-4269-9a40-644ae2817c8c@github.com>
 <ifZsI1jsvf71Twme2hV32NVqt-Xit9kXRQsqpE_T-tM=.b5e2c96e-fcdf-4824-93bd-4dd062ebb511@github.com>
Message-ID: <bPoI9M99o3elWNNucK3b91u-0iw_6_HhHdoypcmOjFE=.f37f75b8-b4c4-4c13-91c7-6f248256e1c3@github.com>

On Thu, 10 Apr 2025 11:23:57 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a minor doc change to clarify that java.net.http.HttpClient only supports HTTP Basic authentication.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright update

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24550#pullrequestreview-2756463816

From vyazici at openjdk.org  Thu Apr 10 12:44:37 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Apr 2025 12:44:37 GMT
Subject: RFR: 8354276: Strict HTTP header validation
In-Reply-To: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
Message-ID: <mnYYhCMDZr8v8RZ-lEv6dyYhX_AAcPSDjp1Z3xoGUCk=.a7cf7ce0-df81-4976-adf5-3bb6b4a602ac@github.com>

On Thu, 10 Apr 2025 11:37:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
> 
> This PR adds the following validation:
> - pseudo-headers defined for requests are rejected in responses and push streams
> - pseudo-headers defined for responses are rejected in push promises
> - connection headers are rejected in responses and push streams
> 
> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
> 
> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.

test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 30:

> 28:  * @build jdk.httpclient.test.lib.http2.Http2TestServer jdk.test.lib.net.SimpleSSLContext
> 29:  * @run testng/othervm -Djdk.internal.httpclient.debug=true BadHeadersTest
> 30:  * @summary This test verifies the behaviour of the HttpClient when presented

Shall we update the `@bug` field too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2037254709

From vyazici at openjdk.org  Thu Apr 10 12:51:41 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 10 Apr 2025 12:51:41 GMT
Subject: RFR: 8354276: Strict HTTP header validation
In-Reply-To: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
Message-ID: <rnMtB7VEzdCKn6Wc948_WmdlIh-pNS6B3shM5Lvc4sI=.2e39cd37-4eeb-4725-be60-b28adeb35832@github.com>

On Thu, 10 Apr 2025 11:37:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
> 
> This PR adds the following validation:
> - pseudo-headers defined for requests are rejected in responses and push streams
> - pseudo-headers defined for responses are rejected in push promises
> - connection headers are rejected in responses and push streams
> 
> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
> 
> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.

src/java.net.http/share/classes/jdk/internal/net/http/common/ValidatingHeadersConsumer.java line 46:

> 44:         REQUEST,
> 45:         RESPONSE,
> 46:         TRAILER

Do we need `TRAILER`, given we don't use it, AFAIU?

test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 83:

> 81:         of(entry(":status", "200"),  entry("hello", "DE" + ((char) 0x7F) + "L")),  // Bad byte in value
> 82:         of(entry(":status", "200"),  entry("connection", "close")),                // Prohibited connection-specific header
> 83:         of(entry(":status", "200"),  entry(":scheme", "https")),                   // Request pseudo-header in response

Shouldn't we instead exhaustively test against all hard-coded header collection in `ValidatingHeadersConsumer`, i.e., `PSEUDO_HEADERS` and `PROHIBITED_HEADERS`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2037267873
PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2037262108

From dfuchs at openjdk.org  Thu Apr 10 12:57:35 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Apr 2025 12:57:35 GMT
Subject: RFR: 8285888: Clarify that java.net.http.HttpClient do NOT support
 Digest authentication [v2]
In-Reply-To: <ifZsI1jsvf71Twme2hV32NVqt-Xit9kXRQsqpE_T-tM=.b5e2c96e-fcdf-4824-93bd-4dd062ebb511@github.com>
References: <6MVPnINp7uqeWzO6kU7kcy6b9pwnIaHxMmxM6jp8mzg=.48fb20d6-556f-4269-9a40-644ae2817c8c@github.com>
 <ifZsI1jsvf71Twme2hV32NVqt-Xit9kXRQsqpE_T-tM=.b5e2c96e-fcdf-4824-93bd-4dd062ebb511@github.com>
Message-ID: <yfml6YSq4r8ldNhcDMFWvp-PCHMYSnd9-ZPzM-vFCmA=.9801fccd-2569-440a-a67d-3033ff3dbc08@github.com>

On Thu, 10 Apr 2025 11:23:57 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a minor doc change to clarify that java.net.http.HttpClient only supports HTTP Basic authentication.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright update

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24550#pullrequestreview-2756591541

From dfuchs at openjdk.org  Thu Apr 10 13:05:38 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Apr 2025 13:05:38 GMT
Subject: RFR: 8354276: Strict HTTP header validation
In-Reply-To: <rnMtB7VEzdCKn6Wc948_WmdlIh-pNS6B3shM5Lvc4sI=.2e39cd37-4eeb-4725-be60-b28adeb35832@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <rnMtB7VEzdCKn6Wc948_WmdlIh-pNS6B3shM5Lvc4sI=.2e39cd37-4eeb-4725-be60-b28adeb35832@github.com>
Message-ID: <akiGG8KzleBaUdByko4lYTxkuHcxjIfj1A6KalqnbSc=.1484d7f5-7374-4a04-8444-d430f32f211b@github.com>

On Thu, 10 Apr 2025 12:48:32 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/ValidatingHeadersConsumer.java line 46:
> 
>> 44:         REQUEST,
>> 45:         RESPONSE,
>> 46:         TRAILER
> 
> Do we need `TRAILER`, given we don't use it, AFAIU?

We have no way to relay trailers to the caller code at the moment. But we can't prevent servers to send them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2037297602

From dfuchs at openjdk.org  Thu Apr 10 13:05:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Apr 2025 13:05:36 GMT
Subject: RFR: 8354276: Strict HTTP header validation
In-Reply-To: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
Message-ID: <1VRWQskIgo-uVC9IIKIX1mekpk8VMtFHdgj-fUPBmHw=.5f8c2e1c-0b90-476d-a071-b5695b4288c0@github.com>

On Thu, 10 Apr 2025 11:37:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
> 
> This PR adds the following validation:
> - pseudo-headers defined for requests are rejected in responses and push streams
> - pseudo-headers defined for responses are rejected in push promises
> - connection headers are rejected in responses and push streams
> 
> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
> 
> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.

> @dfuch has indicated that a [compatibility and specification](https://wiki.openjdk.org/display/csr/Main) (CSR) request is needed for this pull request.

There will be an observable change of behaviour for clients if for instance, a response contains a `connection: close` header added by custom code on the server side.

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

PR Comment: https://git.openjdk.org/jdk/pull/24569#issuecomment-2792717783

From djelinski at openjdk.org  Thu Apr 10 13:26:25 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 10 Apr 2025 13:26:25 GMT
Subject: RFR: 8354276: Strict HTTP header validation
In-Reply-To: <rnMtB7VEzdCKn6Wc948_WmdlIh-pNS6B3shM5Lvc4sI=.2e39cd37-4eeb-4725-be60-b28adeb35832@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <rnMtB7VEzdCKn6Wc948_WmdlIh-pNS6B3shM5Lvc4sI=.2e39cd37-4eeb-4725-be60-b28adeb35832@github.com>
Message-ID: <IhogQcpQ4hWIJe-1usO6scmpMbc3NZ0sI9DOZrlUnuw=.fcfc6c96-5743-4963-a34e-26b494fe12d7@github.com>

On Thu, 10 Apr 2025 12:45:40 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 83:
> 
>> 81:         of(entry(":status", "200"),  entry("hello", "DE" + ((char) 0x7F) + "L")),  // Bad byte in value
>> 82:         of(entry(":status", "200"),  entry("connection", "close")),                // Prohibited connection-specific header
>> 83:         of(entry(":status", "200"),  entry(":scheme", "https")),                   // Request pseudo-header in response
> 
> Shouldn't we instead exhaustively test against all hard-coded header collection in `ValidatingHeadersConsumer`, i.e., `PSEUDO_HEADERS` and `PROHIBITED_HEADERS`?

We could. I don't think it adds much value though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2037385857

From djelinski at openjdk.org  Thu Apr 10 13:31:40 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 10 Apr 2025 13:31:40 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v2]
In-Reply-To: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
Message-ID: <R9DDTkjxFA4vJ99b8LL5LtNTOP4on3dR4kJ2NA6DtZk=.7d43f492-0410-40ee-bd7b-7d724d324c97@github.com>

> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
> 
> This PR adds the following validation:
> - pseudo-headers defined for requests are rejected in responses and push streams
> - pseudo-headers defined for responses are rejected in push promises
> - connection headers are rejected in responses and push streams
> 
> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
> 
> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:

 - Remove trailers
 - Add bug id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24569/files
  - new: https://git.openjdk.org/jdk/pull/24569/files/45121f44..c7b28290

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24569/head:pull/24569

PR: https://git.openjdk.org/jdk/pull/24569

From djelinski at openjdk.org  Thu Apr 10 13:31:40 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 10 Apr 2025 13:31:40 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v2]
In-Reply-To: <akiGG8KzleBaUdByko4lYTxkuHcxjIfj1A6KalqnbSc=.1484d7f5-7374-4a04-8444-d430f32f211b@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <rnMtB7VEzdCKn6Wc948_WmdlIh-pNS6B3shM5Lvc4sI=.2e39cd37-4eeb-4725-be60-b28adeb35832@github.com>
 <akiGG8KzleBaUdByko4lYTxkuHcxjIfj1A6KalqnbSc=.1484d7f5-7374-4a04-8444-d430f32f211b@github.com>
Message-ID: <FlRv_GiNGvFCHM05Qkh-DnYSwLM9Z55HEPsNeECzPjQ=.8d70569f-121c-419d-a160-160865b44174@github.com>

On Thu, 10 Apr 2025 12:59:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/common/ValidatingHeadersConsumer.java line 46:
>> 
>>> 44:         REQUEST,
>>> 45:         RESPONSE,
>>> 46:         TRAILER
>> 
>> Do we need `TRAILER`, given we don't use it, AFAIU?
>
> We have no way to relay trailers to the caller code at the moment. But we can't prevent servers to send them.

Removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2037400492

From djelinski at openjdk.org  Thu Apr 10 13:31:41 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 10 Apr 2025 13:31:41 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v2]
In-Reply-To: <mnYYhCMDZr8v8RZ-lEv6dyYhX_AAcPSDjp1Z3xoGUCk=.a7cf7ce0-df81-4976-adf5-3bb6b4a602ac@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <mnYYhCMDZr8v8RZ-lEv6dyYhX_AAcPSDjp1Z3xoGUCk=.a7cf7ce0-df81-4976-adf5-3bb6b4a602ac@github.com>
Message-ID: <EH1Goq9Z_unOwot2mbgPaxEfXGIyONWvZffrBY3Q1Bo=.c261e7cd-f49b-45e1-85b0-83e866b9490b@github.com>

On Thu, 10 Apr 2025 12:41:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove trailers
>>  - Add bug id
>
> test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 30:
> 
>> 28:  * @build jdk.httpclient.test.lib.http2.Http2TestServer jdk.test.lib.net.SimpleSSLContext
>> 29:  * @run testng/othervm -Djdk.internal.httpclient.debug=true BadHeadersTest
>> 30:  * @summary This test verifies the behaviour of the HttpClient when presented
> 
> Shall we update the `@bug` field too?

updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2037400087

From dfuchs at openjdk.org  Thu Apr 10 13:55:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Apr 2025 13:55:30 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v12]
In-Reply-To: <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
Message-ID: <D8jiIFBf62wV8I9K6Ec6LXQ08D1gsCxcDrfLZGJIbpw=.bcae452f-80ef-4856-8420-a30aad7dc439@github.com>

On Tue, 8 Apr 2025 19:27:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `@implNote` to state that the built-in is always non-empty

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 129:

> 127:                 throw new RuntimeException("failed closing server", serverException);
> 128:             }
> 129:         }

The message here seems to be wrong. Can we use something less exotic to start the server too, and start it, for instance in the calling code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2037478237

From abarashev at openjdk.org  Thu Apr 10 13:57:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 10 Apr 2025 13:57:08 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by
 default are incorrectly allowed in TLSv1.3 when re-enabled
Message-ID: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>

MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:


Any endpoint receiving any certificate which it would need to
validate using any signature algorithm using an MD5 hash MUST abort
the handshake with a "bad_certificate" alert.



The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.

While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.

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

Commit messages:
 - Cosmetic test changes
 - Optimize imports
 - A couple of typo fixes
 - Abort the handshake with a bad_certificate alert on MD5 and SHA1
 - Update test run directive. Remove unnecessary comments
 - Update unit test
 - Unit test
 - 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled

Changes: https://git.openjdk.org/jdk/pull/24425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350807
  Stats: 501 lines in 11 files changed: 426 ins; 42 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From dfuchs at openjdk.org  Thu Apr 10 14:01:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Apr 2025 14:01:00 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v12]
In-Reply-To: <D8jiIFBf62wV8I9K6Ec6LXQ08D1gsCxcDrfLZGJIbpw=.bcae452f-80ef-4856-8420-a30aad7dc439@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
 <D8jiIFBf62wV8I9K6Ec6LXQ08D1gsCxcDrfLZGJIbpw=.bcae452f-80ef-4856-8420-a30aad7dc439@github.com>
Message-ID: <kaVeZSOWOn_GZk-TMbcAtPxByL3K2FH3hjuKGnVvAYY=.b3a5fe5f-f9dc-4746-a8b2-19edec724eb9@github.com>

On Thu, 10 Apr 2025 13:52:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add `@implNote` to state that the built-in is always non-empty
>
> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 129:
> 
>> 127:                 throw new RuntimeException("failed closing server", serverException);
>> 128:             }
>> 129:         }
> 
> The message here seems to be wrong. Can we use something less exotic to start the server too, and start it, for instance in the calling code?

And also maybe log something after it's started - including the server authority where it's listening at?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2037493825

From dfuchs at openjdk.org  Thu Apr 10 14:00:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Apr 2025 14:00:58 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v12]
In-Reply-To: <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
Message-ID: <fpuI8-_OQIxav50T3SZeY9Ne01X3w-zQzUPit4c9dUY=.61f33c67-02fb-4b67-bf2a-9d2c409bff57@github.com>

On Tue, 8 Apr 2025 19:27:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `@implNote` to state that the built-in is always non-empty

Changes requested by dfuchs (Reviewer).

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 171:

> 169:                             String message = "Server[%s] has failed! (connectionKey=%s, responseBody=%s)"
> 170:                                     .formatted(serverId, connectionKey, responseBody);
> 171:                             throw new RuntimeException(message, ioe);

I would recommend logging something here before throwing the exception. For instance calling `ioe.printStackTrace()`. There's not supposed to be one, and if there  is one it's not guaranteed that throwing it will ensure that it gets logged. The client might fail with some other error, or the test may timeout, and we will never know what happened.

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

PR Review: https://git.openjdk.org/jdk/pull/24154#pullrequestreview-2756948977
PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2037489181

From mullan at openjdk.org  Thu Apr 10 15:12:45 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Apr 2025 15:12:45 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>
Message-ID: <ikjeuMVQkSWmEtExqnCh9-x_fLondaivhSTB3cmdA48=.e3dc8213-86c2-4f03-8e6c-1e1c9eef9cc1@github.com>

On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs 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 10 additional commits since the last revision:
> 
>  - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
>    SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
>  - Merge branch 'master' into 8353641-deprecate-premission-classes
>  - Missing suppresswarnings
>  - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
>    Remove dead code from ForkJoinPool.
>    Add @SuppressWarnings("remove")
>  - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
>  - Update copyright in WindowsFileCopy
>  - Remove unused import of LinkPermission
>  - Updated style of @Deprecated to match most existing @Deprecated annotations
>    `since` comes before `forRemoval`
>    No spaces around `=`
>  - Add SuppressWarnings to a Windows source missed earlier.
>  - 8353641: Deprecate core library permission classes for removal
>    
>    Now that the Security Manager is permanently disabled, the following permission classes
>    in the core libraries area can be deprecated for removal as they are no longer useful:
>    FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
>    RuntimePermission, and SerializablePermission
>    
>    @Deprecated(forRemoval = true, since="25")
>    Is added to each class and the existing @apiNote is converted to @deprected

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24444#pullrequestreview-2757226356

From michaelm at openjdk.org  Thu Apr 10 15:29:00 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 10 Apr 2025 15:29:00 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v2]
In-Reply-To: <R9DDTkjxFA4vJ99b8LL5LtNTOP4on3dR4kJ2NA6DtZk=.7d43f492-0410-40ee-bd7b-7d724d324c97@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <R9DDTkjxFA4vJ99b8LL5LtNTOP4on3dR4kJ2NA6DtZk=.7d43f492-0410-40ee-bd7b-7d724d324c97@github.com>
Message-ID: <lYnJTMDPeFMA95sxphphUptGwr1rjlxe7h6NDfoRfOU=.8dbcec8a-f580-4290-b63f-fdb70e0b2543@github.com>

On Thu, 10 Apr 2025 13:31:40 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailers
>  - Add bug id

src/java.net.http/share/classes/jdk/internal/net/http/common/ValidatingHeadersConsumer.java line 46:

> 44:         REQUEST,
> 45:         RESPONSE,
> 46:     }

Suggestion:

    }
    
    // Map of permitted pseudo headers in requests and responses

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2037678052

From djelinski at openjdk.org  Thu Apr 10 15:35:53 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 10 Apr 2025 15:35:53 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v3]
In-Reply-To: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
Message-ID: <y3Kbv2Qs_MQLqSyIUBCFcssHzYXXXU1wyCf6jIqoUnA=.094965b9-c000-4678-b8ab-40bfd0426870@github.com>

> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
> 
> This PR adds the following validation:
> - pseudo-headers defined for requests are rejected in responses and push streams
> - pseudo-headers defined for responses are rejected in push promises
> - connection headers are rejected in responses and push streams
> 
> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
> 
> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Add suggested comment to PSEUDO_HEADERS
  
  Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24569/files
  - new: https://git.openjdk.org/jdk/pull/24569/files/c7b28290..9c945cc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24569/head:pull/24569

PR: https://git.openjdk.org/jdk/pull/24569

From djelinski at openjdk.org  Thu Apr 10 16:35:01 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 10 Apr 2025 16:35:01 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v4]
In-Reply-To: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
Message-ID: <qxpuO5Luok2GIOJK3J3ltC-BksqJG13rFKyWkSPSWUM=.89c6e06d-9273-409d-a747-83b22c113303@github.com>

> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
> 
> This PR adds the following validation:
> - pseudo-headers defined for requests are rejected in responses and push streams
> - pseudo-headers defined for responses are rejected in push promises
> - connection headers are rejected in responses and push streams
> 
> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
> 
> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:

 - Fix whitespace
 - Use ProtocolException for malformed headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24569/files
  - new: https://git.openjdk.org/jdk/pull/24569/files/9c945cc1..4c7f30f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=02-03

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24569/head:pull/24569

PR: https://git.openjdk.org/jdk/pull/24569

From jlu at openjdk.org  Thu Apr 10 18:47:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Apr 2025 18:47:53 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
 <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
Message-ID: <9aQcWun5KNgHgELVwkc3478_RtqfhRL1Cxvyn2Yl0Nw=.07ee596f-e738-4796-8d27-14621ed8860c@github.com>

On Thu, 10 Apr 2025 08:44:28 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace InputStreamReader with BufferedReader
>
> FWIW, I checked out the revision of the commit previous to this change and found the following:
> 
> 
> % git checkout b55e418a077791b39992042411cde97f68dc39fe^ 
> % find src -name "*.properties" | xargs file | grep -v ASCII
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: 
>   ISO-8859 text
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
>   Unicode text, UTF-8 text, with very long lines (322)
> 
> 
> Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.

This conversion was performed under the assumption of ASCII set and Unicode escape sequences, which is the format we expect for the translation process for .properties files. That file should have been omitted from this change. Thank you @eirbjo and @magicus for the analysis and checking!

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2794828598

From rriggs at openjdk.org  Thu Apr 10 19:22:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Apr 2025 19:22:40 GMT
Subject: Integrated: 8353641: Deprecate core library permission classes for
 removal
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <HtfmPyZbbd3pth_MbkOYyTAm1hO8XB4qFYP8iPteFs8=.990be209-2350-4039-b576-16681664fd20@github.com>

On Fri, 4 Apr 2025 12:37:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

This pull request has now been integrated.

Changeset: af5db513
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af5db513060db5f89c071f531e6111c69fcd7370
Stats:     54 lines in 17 files changed: 26 ins; 8 del; 20 mod

8353641: Deprecate core library permission classes for removal

Reviewed-by: mullan, iris

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

PR: https://git.openjdk.org/jdk/pull/24444

From michaelm at openjdk.org  Thu Apr 10 21:19:41 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 10 Apr 2025 21:19:41 GMT
Subject: Integrated: 8285888: Clarify that java.net.http.HttpClient do NOT
 support Digest authentication
In-Reply-To: <6MVPnINp7uqeWzO6kU7kcy6b9pwnIaHxMmxM6jp8mzg=.48fb20d6-556f-4269-9a40-644ae2817c8c@github.com>
References: <6MVPnINp7uqeWzO6kU7kcy6b9pwnIaHxMmxM6jp8mzg=.48fb20d6-556f-4269-9a40-644ae2817c8c@github.com>
Message-ID: <KVZMairLn4yfAfboaqngFUHQwBaygeCZxy23csHLHOI=.0cf8602b-b8e6-4f2d-b17c-e1ed2bf66826@github.com>

On Wed, 9 Apr 2025 14:08:06 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a minor doc change to clarify that java.net.http.HttpClient only supports HTTP Basic authentication.
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: e35f67b9
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e35f67b908a9e62fa6c18775d25a6b698cea8305
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8285888: Clarify that java.net.http.HttpClient do NOT support Digest authentication

Reviewed-by: jpai, dfuchs

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

PR: https://git.openjdk.org/jdk/pull/24550

From michaelm at openjdk.org  Thu Apr 10 21:26:21 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 10 Apr 2025 21:26:21 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  update to minimise code changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/f5501d18..c41146b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=03-04

  Stats: 208 lines in 26 files changed: 16 ins; 61 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From michaelm at openjdk.org  Thu Apr 10 21:31:31 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 10 Apr 2025 21:31:31 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
Message-ID: <FVaEr6y4FNzivtR-V1BPH96Xaa8CgVRJ-wmNKWk0-_4=.efa83883-ab10-4b7f-bd24-e6558c86693d@github.com>

On Thu, 10 Apr 2025 21:26:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to minimise code changes

I've just updated the PR with a change that replaces the new methods of the form `throwException()` with the previous pattern of the form `throw new XException`. This reduces the code changes a bit further and is more readable.

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2795207656

From eirbjo at openjdk.org  Fri Apr 11 08:01:31 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Apr 2025 08:01:31 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v3]
In-Reply-To: <poFJi6yAGv-ncgCC0U17egyN1tKuS-31499oYFFOj4w=.fa7128f6-fef2-469b-a994-d7faceda2684@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <PHxV7hdz3tTQwkL77RWZQjywGB2Catn0zWodW7c6Pw0=.34fb4891-6b6a-48a4-bca5-50e5778d0d8f@github.com>
 <TQDE-jCNJuKObJLUhsRqwng_zvBH1wG27YpDCegxoqA=.74c9703f-4ae2-4015-a573-c039787783b5@github.com>
 <PFuU80VhHUdAESyK6BvIQOv4qqvXi7H_LndYzxKnT-Y=.7ae28607-bd8d-47c9-a5d6-881d5eb3e49d@github.com>
 <eoSQ5kmLLbbgnrAgX0i-XFtZppOGur87qZyvqb4TIFU=.356a6b8a-25f6-401b-88ae-139d0bae8074@github.com>
 <iyRsR0pzra--OWcc7ox8wzURZJXz0n9xmN-_E33Kd1I=.4af9b40e-85b0-4b4e-90a5-a0603b7a3ca8@github.com>
 <poFJi6yAGv-ncgCC0U17egyN1tKuS-31499oYFFOj4w=.fa7128f6-fef2-469b-a994-d7faceda2684@github.com>
Message-ID: <wdNcIRxYK2Rgv1voFPd5A_F3WeHNlwFfms3l5GIcUi4=.7d9d7d4e-ba1d-4e12-b5ce-5909f5971b06@github.com>

On Fri, 4 Apr 2025 10:48:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Generally looks good.

Does this mean you think the PR is good for approval now that the IP version aspect has been taken care of?

Or would you like more time/people to review this test-only enhancement?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24418#discussion_r2039012300

From dfuchs at openjdk.org  Fri Apr 11 09:06:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 09:06:28 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
Message-ID: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>

Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

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

Commit messages:
 - 8353642: Deprecate networking permission classes for removal

Changes: https://git.openjdk.org/jdk/pull/24592/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24592&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353642
  Stats: 58 lines in 12 files changed: 36 ins; 4 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/24592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24592/head:pull/24592

PR: https://git.openjdk.org/jdk/pull/24592

From vyazici at openjdk.org  Fri Apr 11 09:09:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 11 Apr 2025 09:09:42 GMT
Subject: Integrated: 8353949: HttpHeaders.firstValueAsLong unnecessarily boxes
 to Long
In-Reply-To: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>
References: <8dSiPNWSuFsPASQ60k2bBG5ZuxVcJd-QIKsP7EBLHZc=.48c5575a-571b-408d-9e65-c041f3786b0c@github.com>
Message-ID: <ay_RyCBX0SHKWht4K4dqVUdCkrbHSpAgDcB2hHcFHjs=.7b26f02b-cd3e-4fe1-bb01-f73b4c208e4d@github.com>

On Thu, 10 Apr 2025 05:47:09 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Avoid unnecessary boxing in `HttpHeaders::firstValueAsLong`.

This pull request has now been integrated.

Changeset: e1b67709
Author:    Volkan Yazici <vyazici at openjdk.org>
Committer: Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1b677091e0f7860762695ae2e3cff2b63ff9d39
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8353949: HttpHeaders.firstValueAsLong unnecessarily boxes to Long

Reviewed-by: dfuchs, djelinski, michaelm

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

PR: https://git.openjdk.org/jdk/pull/24561

From dfuchs at openjdk.org  Fri Apr 11 10:01:26 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 10:01:26 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
Message-ID: <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>

> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Missing white spaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24592/files
  - new: https://git.openjdk.org/jdk/pull/24592/files/e9dc4146..9b371b3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24592&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24592&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24592/head:pull/24592

PR: https://git.openjdk.org/jdk/pull/24592

From dfuchs at openjdk.org  Fri Apr 11 10:01:26 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 10:01:26 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
In-Reply-To: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
Message-ID: <YMuW-8YlyN8IL-7hdfdCko8FUw2PTf-WQ20Clz9ZU7A=.d0c0dbcd-8918-43a2-85a4-8f6afdee9c72@github.com>

On Fri, 11 Apr 2025 09:00:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

The CSR is also ready to be reviewed at [https://bugs.openjdk.org/browse/JDK-8354406](https://bugs.openjdk.org/browse/JDK-8354406)

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

PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796425675

From djelinski at openjdk.org  Fri Apr 11 11:00:26 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 11 Apr 2025 11:00:26 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
Message-ID: <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>

On Fri, 11 Apr 2025 10:01:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing white spaces

src/java.base/share/classes/java/net/HttpURLConnection.java line 617:

> 615:      * {@link java.security.AllPermission}.
> 616:      */
> 617:     @Deprecated(since = "25")

can this (and all other getPermission methods) be "forRemoval=true"?

src/java.base/share/classes/java/security/CodeSource.java line 468:

> 466:                 }
> 467:                 @SuppressWarnings("removal")
> 468:                 var result = this.sp.implies(that.sp);

Will we need to rewrite this code without SocketPermissions? Can we remove it, maybe? It is only used by CodeSource.implies, which is not used by the JDK (but may be used elsewhere).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039291810
PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039304662

From djelinski at openjdk.org  Fri Apr 11 11:12:40 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 11 Apr 2025 11:12:40 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
Message-ID: <jSKaMQwnV-o2JekwUPSkleTLlt78kd239YomdDoyS5w=.584cebff-fb5f-4b68-8fc6-ad23eb42a81b@github.com>

On Fri, 11 Apr 2025 10:55:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing white spaces
>
> src/java.base/share/classes/java/security/CodeSource.java line 468:
> 
>> 466:                 }
>> 467:                 @SuppressWarnings("removal")
>> 468:                 var result = this.sp.implies(that.sp);
> 
> Will we need to rewrite this code without SocketPermissions? Can we remove it, maybe? It is only used by CodeSource.implies, which is not used by the JDK (but may be used elsewhere).

also the JavaDoc of the implies method references the SocketPermission. That will also need to be cleaned up at some point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039324745

From djelinski at openjdk.org  Fri Apr 11 11:19:27 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 11 Apr 2025 11:19:27 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
Message-ID: <jtpf0LUuSokcX2C4Wv97UaLGB5krwE2ULefADEhr2e4=.ba0029ec-f85d-4335-99d6-008748109c6c@github.com>

On Fri, 11 Apr 2025 10:01:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing white spaces

src/java.base/share/classes/java/net/SocketPermission.java line 1311:

> 1309: 
> 1310: @SuppressWarnings("removal")
> 1311: @Deprecated(since = "25", forRemoval = true)

this class is internal, no need to deprecate

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039335050

From dfuchs at openjdk.org  Fri Apr 11 11:34:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 11:34:32 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
Message-ID: <k0nTRZe9px2bRgNruCYr0XuYaBxFo2Bqm32Ld0fiyhc=.6c1e9e91-1e97-466d-bfb8-f6fe58427103@github.com>

On Fri, 11 Apr 2025 10:45:20 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing white spaces
>
> src/java.base/share/classes/java/net/HttpURLConnection.java line 617:
> 
>> 615:      * {@link java.security.AllPermission}.
>> 616:      */
>> 617:     @Deprecated(since = "25")
> 
> can this (and all other getPermission methods) be "forRemoval=true"?

Possibly. @AlanBateman may have some thoughts on this.

> src/java.base/share/classes/java/net/SocketPermission.java line 1311:
> 
>> 1309: 
>> 1310: @SuppressWarnings("removal")
>> 1311: @Deprecated(since = "25", forRemoval = true)
> 
> this class is internal, no need to deprecate

It helps getting warnings at the place where the class is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039358351
PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039360730

From dfuchs at openjdk.org  Fri Apr 11 11:34:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 11:34:33 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <jSKaMQwnV-o2JekwUPSkleTLlt78kd239YomdDoyS5w=.584cebff-fb5f-4b68-8fc6-ad23eb42a81b@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
 <jSKaMQwnV-o2JekwUPSkleTLlt78kd239YomdDoyS5w=.584cebff-fb5f-4b68-8fc6-ad23eb42a81b@github.com>
Message-ID: <_lrzJTVqcfATXdXToFeL69PLIu9LRQ37BFmmlFYvTWQ=.8e3a7e15-e5a5-45dc-b0d1-362950b51939@github.com>

On Fri, 11 Apr 2025 11:10:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/CodeSource.java line 468:
>> 
>>> 466:                 }
>>> 467:                 @SuppressWarnings("removal")
>>> 468:                 var result = this.sp.implies(that.sp);
>> 
>> Will we need to rewrite this code without SocketPermissions? Can we remove it, maybe? It is only used by CodeSource.implies, which is not used by the JDK (but may be used elsewhere).
>
> also the JavaDoc of the implies method references the SocketPermission. That will also need to be cleaned up at some point.

That will be left over for someone in security-libs to cleanup this code at their convenience before we remove SocketException.

Hmmm... If the public API references SocketException we might have to deprecate in this PR too. Not sure what the implications are. Maybe @seanjmullan can advise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039353439

From alanb at openjdk.org  Fri Apr 11 11:37:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 11 Apr 2025 11:37:36 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <k0nTRZe9px2bRgNruCYr0XuYaBxFo2Bqm32Ld0fiyhc=.6c1e9e91-1e97-466d-bfb8-f6fe58427103@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
 <k0nTRZe9px2bRgNruCYr0XuYaBxFo2Bqm32Ld0fiyhc=.6c1e9e91-1e97-466d-bfb8-f6fe58427103@github.com>
Message-ID: <rfBaIvhdw5kWJ3JJmezz5-aD0b0n8U5frLH8pF0EL8w=.61e58686-1469-4157-afd9-cced4459c23e@github.com>

On Fri, 11 Apr 2025 11:30:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/HttpURLConnection.java line 617:
>> 
>>> 615:      * {@link java.security.AllPermission}.
>>> 616:      */
>>> 617:     @Deprecated(since = "25")
>> 
>> can this (and all other getPermission methods) be "forRemoval=true"?
>
> Possibly. @AlanBateman may have some thoughts on this.

I think we should at least consider deprecating URLConnection.getPermission and HttpURLConnection.getPermission for removal, only because I don't immediately see the advantage of doing it in two steps for these two APIs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039366899

From dfuchs at openjdk.org  Fri Apr 11 11:50:24 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 11:50:24 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <rfBaIvhdw5kWJ3JJmezz5-aD0b0n8U5frLH8pF0EL8w=.61e58686-1469-4157-afd9-cced4459c23e@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
 <k0nTRZe9px2bRgNruCYr0XuYaBxFo2Bqm32Ld0fiyhc=.6c1e9e91-1e97-466d-bfb8-f6fe58427103@github.com>
 <rfBaIvhdw5kWJ3JJmezz5-aD0b0n8U5frLH8pF0EL8w=.61e58686-1469-4157-afd9-cced4459c23e@github.com>
Message-ID: <LgSm4MVnNgaaLWF2VWlsvXj4eEfe6R442QPXSdvdSRw=.c8bf4811-1a8c-4d03-8e2a-3faaf2739516@github.com>

On Fri, 11 Apr 2025 11:34:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Possibly. @AlanBateman may have some thoughts on this.
>
> I think we should at least consider deprecating URLConnection.getPermission and HttpURLConnection.getPermission for removal, only because I don't immediately see the advantage of doing it in two steps for these two APIs.

Thanks - I will do that then

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039391997

From djelinski at openjdk.org  Fri Apr 11 12:04:24 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 11 Apr 2025 12:04:24 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
Message-ID: <j4b_gXM-5ivPvPDfWtOHF9AE8HkWx0odnBZwr4Ijb9A=.05e0ba61-c877-4d51-9505-de6fb204984e@github.com>

On Fri, 11 Apr 2025 10:01:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing white spaces

The GHA failure (Windows) appears to be related.

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

PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796715234

From dfuchs at openjdk.org  Fri Apr 11 12:26:38 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 12:26:38 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v3]
In-Reply-To: <wdNcIRxYK2Rgv1voFPd5A_F3WeHNlwFfms3l5GIcUi4=.7d9d7d4e-ba1d-4e12-b5ce-5909f5971b06@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <PHxV7hdz3tTQwkL77RWZQjywGB2Catn0zWodW7c6Pw0=.34fb4891-6b6a-48a4-bca5-50e5778d0d8f@github.com>
 <TQDE-jCNJuKObJLUhsRqwng_zvBH1wG27YpDCegxoqA=.74c9703f-4ae2-4015-a573-c039787783b5@github.com>
 <PFuU80VhHUdAESyK6BvIQOv4qqvXi7H_LndYzxKnT-Y=.7ae28607-bd8d-47c9-a5d6-881d5eb3e49d@github.com>
 <eoSQ5kmLLbbgnrAgX0i-XFtZppOGur87qZyvqb4TIFU=.356a6b8a-25f6-401b-88ae-139d0bae8074@github.com>
 <iyRsR0pzra--OWcc7ox8wzURZJXz0n9xmN-_E33Kd1I=.4af9b40e-85b0-4b4e-90a5-a0603b7a3ca8@github.com>
 <poFJi6yAGv-ncgCC0U17egyN1tKuS-31499oYFFOj4w=.fa7128f6-fef2-469b-a994-d7faceda2684@github.com>
 <wdNcIRxYK2Rgv1voFPd5A_F3WeHNlwFfms3l5GIcUi4=.7d9d7d4e-ba1d-4e12-b5ce-5909f5971b06@github.com>
Message-ID: <kswnTGmUA5pQ2ITfDHdIzJbPPoAuOFv_IzuhLg7Ju7A=.fe146a8e-1072-4271-a605-0f0edf8a79a7@github.com>

On Fri, 11 Apr 2025 07:58:43 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Generally looks good. "127.0.0.1" rings alarm bells because we're trying to make our tests independent of the IP versions supported by the machine they run on.
>
>> Generally looks good.
> 
> Does this mean you think the PR is good for approval now that the IP version aspect has been taken care of?
> 
> Or would you like more time/people to review this test-only enhancement?

Sorry - thanks for pinging me.
I tested the change in our CI and the new test seem stable. Approved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24418#discussion_r2039465917

From dfuchs at openjdk.org  Fri Apr 11 12:26:37 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 12:26:37 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v3]
In-Reply-To: <6-DH9HLfhkXR0RazrHG_p668w9lsykybwNh_KrxELt8=.eab8b548-9025-4e4a-85bf-4590b50bd34d@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <6-DH9HLfhkXR0RazrHG_p668w9lsykybwNh_KrxELt8=.eab8b548-9025-4e4a-85bf-4590b50bd34d@github.com>
Message-ID: <L3m2SmlY4wCIKQVvq9D8rth9Q6fKLdXO2qVqH3_lOrk=.6db63fd5-861f-4612-98d0-e52163e72869@github.com>

On Fri, 4 Apr 2025 10:37:58 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this test-only PR which introduces testing of the unspecified but long-standing fallback to FTP for non-local files in the 'file' URL scheme. 
>> 
>> This in preparation for the upcoming proposal to disable the feature by default in JDK-8353440.
>> 
>> Since we cannot reliably bind an FTP server to port 21, the test instead uses an HTTP proxy, binding to an ephemeral port. This menas we don't test non-proxy code paths. We still test that the FTP fallback is used, which is the key point here. (We aim to test file URL connections, not FTP URL connection internals) 
>> 
>> An alternative here could be to just verify that the returned URLConnection is an instance of FtpURLConnection. However, I opted for an end-to-end test here, since the amount of extra code seems reasonable.
>> 
>> By temporarly moving this test to tier1, I was able to confirm this test runs green also on Windows GHA.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a fake host name since no actual FTP request will be attempted

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24418#pullrequestreview-2760195811

From dfuchs at openjdk.org  Fri Apr 11 12:33:25 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 12:33:25 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <j4b_gXM-5ivPvPDfWtOHF9AE8HkWx0odnBZwr4Ijb9A=.05e0ba61-c877-4d51-9505-de6fb204984e@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <j4b_gXM-5ivPvPDfWtOHF9AE8HkWx0odnBZwr4Ijb9A=.05e0ba61-c877-4d51-9505-de6fb204984e@github.com>
Message-ID: <Z9HsGkpg6rIKrOFz7aGLdX3jpC7eO4gs6WtxagvnItw=.1eb795a2-1ccb-4a80-9670-cacf4ceb8990@github.com>

On Fri, 11 Apr 2025 12:01:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The GHA failure (Windows) appears to be related.

Yes - I missed one windows specific file in my original patch. I have a test running in the CI and I am waiting for it to pass before updating the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796783392

From eirbjo at openjdk.org  Fri Apr 11 12:52:34 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Apr 2025 12:52:34 GMT
Subject: RFR: 8353662: Add test for non-local file URL fallback to FTP [v3]
In-Reply-To: <6-DH9HLfhkXR0RazrHG_p668w9lsykybwNh_KrxELt8=.eab8b548-9025-4e4a-85bf-4590b50bd34d@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
 <6-DH9HLfhkXR0RazrHG_p668w9lsykybwNh_KrxELt8=.eab8b548-9025-4e4a-85bf-4590b50bd34d@github.com>
Message-ID: <VIwpBMiP7WvzRnRdBuRT64k85ib3LcTrNohV6PoMFzA=.f7ddfb55-430b-4b58-bca6-8ce078e5279c@github.com>

On Fri, 4 Apr 2025 10:37:58 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this test-only PR which introduces testing of the unspecified but long-standing fallback to FTP for non-local files in the 'file' URL scheme. 
>> 
>> This in preparation for the upcoming proposal to disable the feature by default in JDK-8353440.
>> 
>> Since we cannot reliably bind an FTP server to port 21, the test instead uses an HTTP proxy, binding to an ephemeral port. This menas we don't test non-proxy code paths. We still test that the FTP fallback is used, which is the key point here. (We aim to test file URL connections, not FTP URL connection internals) 
>> 
>> An alternative here could be to just verify that the returned URLConnection is an instance of FtpURLConnection. However, I opted for an end-to-end test here, since the amount of extra code seems reasonable.
>> 
>> By temporarly moving this test to tier1, I was able to confirm this test runs green also on Windows GHA.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a fake host name since no actual FTP request will be attempted

Thanks you Daniel for running this through CI and for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/24418#issuecomment-2796823188

From eirbjo at openjdk.org  Fri Apr 11 12:52:35 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Apr 2025 12:52:35 GMT
Subject: Integrated: 8353662: Add test for non-local file URL fallback to FTP
In-Reply-To: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
References: <isjNyV4kQJU5jjMkeOxpiUaOuffW9HX-6NcndC_-44o=.8ceae3f5-a271-4eb1-9678-b448e9076f7c@github.com>
Message-ID: <guqTxW9IpLRUQL9HPYfPaeoNE2LwVK6Gv-ORMOiJqiw=.223c215e-85fd-4b69-8f3d-9064cfd2fe19@github.com>

On Thu, 3 Apr 2025 15:44:44 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which introduces testing of the unspecified but long-standing fallback to FTP for non-local files in the 'file' URL scheme. 
> 
> This in preparation for the upcoming proposal to disable the feature by default in JDK-8353440.
> 
> Since we cannot reliably bind an FTP server to port 21, the test instead uses an HTTP proxy, binding to an ephemeral port. This menas we don't test non-proxy code paths. We still test that the FTP fallback is used, which is the key point here. (We aim to test file URL connections, not FTP URL connection internals) 
> 
> An alternative here could be to just verify that the returned URLConnection is an instance of FtpURLConnection. However, I opted for an end-to-end test here, since the amount of extra code seems reasonable.
> 
> By temporarly moving this test to tier1, I was able to confirm this test runs green also on Windows GHA.

This pull request has now been integrated.

Changeset: cae7a206
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cae7a206a2f4b47d6757408d62b88be060113ad5
Stats:     145 lines in 1 file changed: 145 ins; 0 del; 0 mod

8353662: Add test for non-local file URL fallback to FTP

Reviewed-by: dfuchs

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

PR: https://git.openjdk.org/jdk/pull/24418

From michaelm at openjdk.org  Fri Apr 11 13:49:27 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 11 Apr 2025 13:49:27 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
Message-ID: <oNcT5NhnJBf4nc_GxNkTSfF90dPovQ2WtN6-YDmnJ6I=.e4d37950-018f-4f7f-a834-b5c52aaaacec@github.com>

On Fri, 11 Apr 2025 10:01:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing white spaces

src/java.base/share/classes/java/security/CodeSource.java line 461:

> 459:                 if (this.sp == null) {
> 460:                     @SuppressWarnings("removal")
> 461:                     var _ = this.sp = new SocketPermission(thisHost, "resolve");

What's the reason for the `var _ =` bit ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039598335

From dfuchs at openjdk.org  Fri Apr 11 13:56:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 13:56:18 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v3]
In-Reply-To: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
Message-ID: <fHztT09Z_JIq9JVtvI-zGxXeod2hd9uyxP3Y7-6SAUo=.fd5a6971-274b-4969-a5ee-bacec4e5bbb9@github.com>

> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback. Deprecate getPermission for removal.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24592/files
  - new: https://git.openjdk.org/jdk/pull/24592/files/9b371b3a..d47a31d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24592&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24592&range=01-02

  Stats: 22 lines in 7 files changed: 5 ins; 7 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24592/head:pull/24592

PR: https://git.openjdk.org/jdk/pull/24592

From dfuchs at openjdk.org  Fri Apr 11 14:00:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 14:00:32 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v2]
In-Reply-To: <Z9HsGkpg6rIKrOFz7aGLdX3jpC7eO4gs6WtxagvnItw=.1eb795a2-1ccb-4a80-9670-cacf4ceb8990@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <j4b_gXM-5ivPvPDfWtOHF9AE8HkWx0odnBZwr4Ijb9A=.05e0ba61-c877-4d51-9505-de6fb204984e@github.com>
 <Z9HsGkpg6rIKrOFz7aGLdX3jpC7eO4gs6WtxagvnItw=.1eb795a2-1ccb-4a80-9670-cacf4ceb8990@github.com>
Message-ID: <BuLdKGcqJo1LsA8UIAdI8N_it8N1Pz7JWIaupRdfnqw=.ff804f7a-18c1-49e5-b99f-d6f3e9589ed3@github.com>

On Fri, 11 Apr 2025 12:31:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The GHA failure (Windows) appears to be related.

Should be fixed now

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

PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796995066

From dfuchs at openjdk.org  Fri Apr 11 14:00:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 14:00:33 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v2]
In-Reply-To: <LgSm4MVnNgaaLWF2VWlsvXj4eEfe6R442QPXSdvdSRw=.c8bf4811-1a8c-4d03-8e2a-3faaf2739516@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
 <k0nTRZe9px2bRgNruCYr0XuYaBxFo2Bqm32Ld0fiyhc=.6c1e9e91-1e97-466d-bfb8-f6fe58427103@github.com>
 <rfBaIvhdw5kWJ3JJmezz5-aD0b0n8U5frLH8pF0EL8w=.61e58686-1469-4157-afd9-cced4459c23e@github.com>
 <LgSm4MVnNgaaLWF2VWlsvXj4eEfe6R442QPXSdvdSRw=.c8bf4811-1a8c-4d03-8e2a-3faaf2739516@github.com>
Message-ID: <BBBvtz4i_6VVHeVJntpm_b2nypOm9JLfSaYz5omSPTU=.92715c6a-13c7-4b98-93b7-90b1e891716c@github.com>

On Fri, 11 Apr 2025 11:47:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I think we should at least consider deprecating URLConnection.getPermission and HttpURLConnection.getPermission for removal, only because I don't immediately see the advantage of doing it in two steps for these two APIs.
>
> Thanks - I will do that then

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039614980

From dfuchs at openjdk.org  Fri Apr 11 14:00:34 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 14:00:34 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v2]
In-Reply-To: <oNcT5NhnJBf4nc_GxNkTSfF90dPovQ2WtN6-YDmnJ6I=.e4d37950-018f-4f7f-a834-b5c52aaaacec@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <oNcT5NhnJBf4nc_GxNkTSfF90dPovQ2WtN6-YDmnJ6I=.e4d37950-018f-4f7f-a834-b5c52aaaacec@github.com>
Message-ID: <GUqHGPI6S5Nysb7tacLGdPU_Hk3dUjClN3g6KVgAxPY=.ae30e73c-8395-4847-af67-5b672005ee38@github.com>

On Fri, 11 Apr 2025 13:47:10 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing white spaces
>
> src/java.base/share/classes/java/security/CodeSource.java line 461:
> 
>> 459:                 if (this.sp == null) {
>> 460:                     @SuppressWarnings("removal")
>> 461:                     var _ = this.sp = new SocketPermission(thisHost, "resolve");
> 
> What's the reason for the `var _ =` bit ?

`@SuppressWarnings` can not be applied to a an expression - it needs a (variable/method/class) declaration

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039613130

From michaelm at openjdk.org  Fri Apr 11 14:58:29 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 11 Apr 2025 14:58:29 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v3]
In-Reply-To: <fHztT09Z_JIq9JVtvI-zGxXeod2hd9uyxP3Y7-6SAUo=.fd5a6971-274b-4969-a5ee-bacec4e5bbb9@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <fHztT09Z_JIq9JVtvI-zGxXeod2hd9uyxP3Y7-6SAUo=.fd5a6971-274b-4969-a5ee-bacec4e5bbb9@github.com>
Message-ID: <O9SFskwbY-Q6p3u7Q_BTkCod6iA8Ls9McAP4G4PO7to=.4f050136-617d-436b-8154-66f3988cc830@github.com>

On Fri, 11 Apr 2025 13:56:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback. Deprecate getPermission for removal.

Looks fine to me.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2760620879

From djelinski at openjdk.org  Fri Apr 11 15:50:43 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 11 Apr 2025 15:50:43 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v3]
In-Reply-To: <fHztT09Z_JIq9JVtvI-zGxXeod2hd9uyxP3Y7-6SAUo=.fd5a6971-274b-4969-a5ee-bacec4e5bbb9@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <fHztT09Z_JIq9JVtvI-zGxXeod2hd9uyxP3Y7-6SAUo=.fd5a6971-274b-4969-a5ee-bacec4e5bbb9@github.com>
Message-ID: <OX_57jdbwWi7r1eTelim-rEzme-amJv7aT9-Ytgfmos=.8795af33-bea9-440a-97fc-860766699001@github.com>

On Fri, 11 Apr 2025 13:56:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback. Deprecate getPermission for removal.

LGTM.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2760802017

From abarashev at openjdk.org  Fri Apr 11 16:09:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 11 Apr 2025 16:09:08 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v2]
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <Exm6-IiIxVBSIteNkTbgRaCBzAlrKeNH2wdlfQnI3f4=.4f62ddfc-9388-49d3-9ee7-6829f4e7b0b3@github.com>

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.

Artur Barashev 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 nine additional commits since the last revision:

 - Merge branch 'master' into JDK-8350807
 - Cosmetic test changes
 - Optimize imports
 - A couple of typo fixes
 - Abort the handshake with a bad_certificate alert on MD5 and SHA1
 - Update test run directive. Remove unnecessary comments
 - Update unit test
 - Unit test
 - 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24425/files
  - new: https://git.openjdk.org/jdk/pull/24425/files/28f12786..134a3264

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=00-01

  Stats: 58077 lines in 1239 files changed: 32407 ins; 21258 del; 4412 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From dfuchs at openjdk.org  Fri Apr 11 18:02:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 18:02:36 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v12]
In-Reply-To: <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
Message-ID: <PWwYkZOw9hBPnhq5fOJ83VvTeGOf8Tk80MeGtpfLK_M=.ead3599a-854d-474a-8f6c-026c22c38afc@github.com>

On Tue, 8 Apr 2025 19:27:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `@implNote` to state that the built-in is always non-empty

Changes requested by dfuchs (Reviewer).

test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 188:

> 186:         private static HttpTestServer createServer(Version version, SSLContext sslContext) {
> 187:             try {
> 188:                 return HttpTestServer.create(version, sslContext, ForkJoinPool.commonPool());

OK - we definitely MUST NOT use the common FJP here. 

1. our HTTP/2 servers start their dispatching thread, which blocks on accept(), in the executor. 
2. the tests will block (CountDownLatch) in the exchange, which is a thread in the executor.
3. the test creates at least two HTTP/2 servers (maybe more) upfront.

If you run this test on a machine that has a low number of processors - say 4 - then the FJP will maybe have 3 threads at most. You can see where that goes...

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

PR Review: https://git.openjdk.org/jdk/pull/24154#pullrequestreview-2761151791
PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2040042478

From dfuchs at openjdk.org  Fri Apr 11 18:07:38 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 18:07:38 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v12]
In-Reply-To: <PWwYkZOw9hBPnhq5fOJ83VvTeGOf8Tk80MeGtpfLK_M=.ead3599a-854d-474a-8f6c-026c22c38afc@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
 <PWwYkZOw9hBPnhq5fOJ83VvTeGOf8Tk80MeGtpfLK_M=.ead3599a-854d-474a-8f6c-026c22c38afc@github.com>
Message-ID: <9BJz90SgBd5cbCY4q8hShnY6x7vRnX2wYl1zmAKzSvo=.239ec904-1255-4e5b-90ce-704ad2307f86@github.com>

On Fri, 11 Apr 2025 17:58:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add `@implNote` to state that the built-in is always non-empty
>
> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 188:
> 
>> 186:         private static HttpTestServer createServer(Version version, SSLContext sslContext) {
>> 187:             try {
>> 188:                 return HttpTestServer.create(version, sslContext, ForkJoinPool.commonPool());
> 
> OK - we definitely MUST NOT use the common FJP here. 
> 
> 1. our HTTP/2 servers start their dispatching thread, which blocks on accept(), in the executor. 
> 2. the tests will block (CountDownLatch) in the exchange, which is a thread in the executor.
> 3. the test creates at least two HTTP/2 servers (maybe more) upfront.
> 
> If you run this test on a machine that has a low number of processors - say 4 - then the FJP will maybe have 3 threads at most. You can see where that goes...

If no executor is provided the HTTP/2 server will create its own. The HTTP/1.1 server however will run the exchange in the dispacher thread - so you need to at least provide an executor for the HTTP/1.1 server if you don't want to wedge when making parallel requests. But not the common FJP ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2040059863

From duke at openjdk.org  Fri Apr 11 18:41:39 2025
From: duke at openjdk.org (Rohitash)
Date: Fri, 11 Apr 2025 18:41:39 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance to
 scan the host/domain name from URI string when the hostname starts
 with number
Message-ID: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>

`scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933

This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.

I benchmarked on local machine for potential regressions.
https://gist.github.com/rk-kmr/cb1a3d59225c17b180a29cc125ebf887


Benchmark                                     Mode     Cnt        Score       Error   Units
URIBenchMark.newImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
URIBenchMark.newImplWithNumberlUrl           thrpt      10        0.004 ?     0.001  ops/ns
URIBenchMark.oldImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
URIBenchMark.oldImplWithNumUrl               thrpt      10        0.001 ?     0.001  ops/ns
URIBenchMark.newImplWithNormalUrl             avgt      10      236.762 ?     8.700   ns/op
URIBenchMark.newImplWithNumberlUrl            avgt      10      264.017 ?     7.274   ns/op
URIBenchMark.oldImplWithNormalUrl             avgt      10      233.853 ?     6.539   ns/op
URIBenchMark.oldImplWithNumUrl                avgt      10     1183.572 ?    29.242   ns/op


I ran following tests.

make test-tier1
make test-tier2
make test TEST=jdk/java/net

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

Commit messages:
 - Update src/java.base/share/classes/java/net/URI.java
 - make test pass
 - add unit test
 - Address PR comments
 - Merge branch 'openjdk:master' into JDK-8353013
 - reuse scan method instead
 - avoid parseInt if scanned digit count > 3

Changes: https://git.openjdk.org/jdk/pull/24295/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24295&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353013
  Stats: 40 lines in 2 files changed: 37 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24295.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24295/head:pull/24295

PR: https://git.openjdk.org/jdk/pull/24295

From xpeng at openjdk.org  Fri Apr 11 18:41:39 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 11 Apr 2025 18:41:39 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number
In-Reply-To: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
Message-ID: <2RxkxeS718pmuM1eVPyaSQsa2TEMfDgFSQ7dezU2v0A=.1b196451-b26f-4278-b3ea-a3263a3b5212@github.com>

On Fri, 28 Mar 2025 15:19:46 GMT, Rohitash <duke at openjdk.org> wrote:

> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
> 
> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
> 
> I benchmarked on local machine for potential regressions.
> https://gist.github.com/rk-kmr/cb1a3d59225c17b180a29cc125ebf887
> 
> 
> Benchmark                                     Mode     Cnt        Score       Error   Units
> URIBenchMark.newImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.newImplWithNumberlUrl           thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNumUrl               thrpt      10        0.001 ?     0.001  ops/ns
> URIBenchMark.newImplWithNormalUrl             avgt      10      236.762 ?     8.700   ns/op
> URIBenchMark.newImplWithNumberlUrl            avgt      10      264.017 ?     7.274   ns/op
> URIBenchMark.oldImplWithNormalUrl             avgt      10      233.853 ?     6.539   ns/op
> URIBenchMark.oldImplWithNumUrl                avgt      10     1183.572 ?    29.242   ns/op
> 
> 
> I ran following tests.
> 
> make test-tier1
> make test-tier2
> make test TEST=jdk/java/net

Looks good to me, thanks.

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

Marked as reviewed by xpeng (Author).

PR Review: https://git.openjdk.org/jdk/pull/24295#pullrequestreview-2726092046

From myankelevich at openjdk.org  Fri Apr 11 18:41:39 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 11 Apr 2025 18:41:39 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number
In-Reply-To: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
Message-ID: <yx_k7OSOfr6_13rw1o-g1XlNws-QkKitccXTLIKo6Fg=.61c31a5a-f10c-408e-991d-06e533cd3105@github.com>

On Fri, 28 Mar 2025 15:19:46 GMT, Rohitash <duke at openjdk.org> wrote:

> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
> 
> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
> 
> I benchmarked on local machine for potential regressions.
> https://gist.github.com/rk-kmr/cb1a3d59225c17b180a29cc125ebf887
> 
> 
> Benchmark                                     Mode     Cnt        Score       Error   Units
> URIBenchMark.newImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.newImplWithNumberlUrl           thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNumUrl               thrpt      10        0.001 ?     0.001  ops/ns
> URIBenchMark.newImplWithNormalUrl             avgt      10      236.762 ?     8.700   ns/op
> URIBenchMark.newImplWithNumberlUrl            avgt      10      264.017 ?     7.274   ns/op
> URIBenchMark.oldImplWithNormalUrl             avgt      10      233.853 ?     6.539   ns/op
> URIBenchMark.oldImplWithNumUrl                avgt      10     1183.572 ?    29.242   ns/op
> 
> 
> I ran following tests.
> 
> make test-tier1
> make test-tier2
> make test TEST=jdk/java/net

Could you please also add  a test for this change/ add a bug id to the existing test if there already is one covering this functionality. Just in case

src/java.base/share/classes/java/net/URI.java line 3429:

> 3427:             int q = scan(p, n, L_DIGIT, H_DIGIT);
> 3428:             if (q <= p) return q;
> 3429: 

Nit: Copyright year

src/java.base/share/classes/java/net/URI.java line 3435:

> 3433: 
> 3434:             // Calculate the number of significant digits (after leading zeros)
> 3435:             int significantDigits = q - i;

Nit: Do you think it might be more clear if this is named something like `significantDigitsNum` or similar? No strong feelings, just confused me a little when I was reading this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24295#issuecomment-2766357418
PR Review Comment: https://git.openjdk.org/jdk/pull/24295#discussion_r2020971319
PR Review Comment: https://git.openjdk.org/jdk/pull/24295#discussion_r2020969734

From duke at openjdk.org  Fri Apr 11 18:41:40 2025
From: duke at openjdk.org (Rohitash)
Date: Fri, 11 Apr 2025 18:41:40 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number
In-Reply-To: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
Message-ID: <l237QvO948GlzzYPj5tUKo71QVq0M-7cCR61kvmeciY=.efd3b121-4e3b-461e-8606-a08938c1147f@github.com>

On Fri, 28 Mar 2025 15:19:46 GMT, Rohitash <duke at openjdk.org> wrote:

> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
> 
> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
> 
> I benchmarked on local machine for potential regressions.
> https://gist.github.com/rk-kmr/cb1a3d59225c17b180a29cc125ebf887
> 
> 
> Benchmark                                     Mode     Cnt        Score       Error   Units
> URIBenchMark.newImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.newImplWithNumberlUrl           thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNumUrl               thrpt      10        0.001 ?     0.001  ops/ns
> URIBenchMark.newImplWithNormalUrl             avgt      10      236.762 ?     8.700   ns/op
> URIBenchMark.newImplWithNumberlUrl            avgt      10      264.017 ?     7.274   ns/op
> URIBenchMark.oldImplWithNormalUrl             avgt      10      233.853 ?     6.539   ns/op
> URIBenchMark.oldImplWithNumUrl                avgt      10     1183.572 ?    29.242   ns/op
> 
> 
> I ran following tests.
> 
> make test-tier1
> make test-tier2
> make test TEST=jdk/java/net

Thanks! I have added unit test.

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

PR Comment: https://git.openjdk.org/jdk/pull/24295#issuecomment-2766792903

From duke at openjdk.org  Fri Apr 11 18:41:40 2025
From: duke at openjdk.org (Rohitash)
Date: Fri, 11 Apr 2025 18:41:40 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number
In-Reply-To: <yx_k7OSOfr6_13rw1o-g1XlNws-QkKitccXTLIKo6Fg=.61c31a5a-f10c-408e-991d-06e533cd3105@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
 <yx_k7OSOfr6_13rw1o-g1XlNws-QkKitccXTLIKo6Fg=.61c31a5a-f10c-408e-991d-06e533cd3105@github.com>
Message-ID: <HiMHKiRO6xCf7KwJDMBDBHlFtpC8t2LqzW0YF7BlL74=.a7ef8704-0482-4306-be5d-cefaff92d6d3@github.com>

On Mon, 31 Mar 2025 12:40:27 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
>> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
>> 
>> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
>> 
>> I benchmarked on local machine for potential regressions.
>> https://gist.github.com/rk-kmr/cb1a3d59225c17b180a29cc125ebf887
>> 
>> 
>> Benchmark                                     Mode     Cnt        Score       Error   Units
>> URIBenchMark.newImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
>> URIBenchMark.newImplWithNumberlUrl           thrpt      10        0.004 ?     0.001  ops/ns
>> URIBenchMark.oldImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
>> URIBenchMark.oldImplWithNumUrl               thrpt      10        0.001 ?     0.001  ops/ns
>> URIBenchMark.newImplWithNormalUrl             avgt      10      236.762 ?     8.700   ns/op
>> URIBenchMark.newImplWithNumberlUrl            avgt      10      264.017 ?     7.274   ns/op
>> URIBenchMark.oldImplWithNormalUrl             avgt      10      233.853 ?     6.539   ns/op
>> URIBenchMark.oldImplWithNumUrl                avgt      10     1183.572 ?    29.242   ns/op
>> 
>> 
>> I ran following tests.
>> 
>> make test-tier1
>> make test-tier2
>> make test TEST=jdk/java/net
>
> src/java.base/share/classes/java/net/URI.java line 3429:
> 
>> 3427:             int q = scan(p, n, L_DIGIT, H_DIGIT);
>> 3428:             if (q <= p) return q;
>> 3429: 
> 
> Nit: Copyright year

Updated.

> src/java.base/share/classes/java/net/URI.java line 3435:
> 
>> 3433: 
>> 3434:             // Calculate the number of significant digits (after leading zeros)
>> 3435:             int significantDigits = q - i;
> 
> Nit: Do you think it might be more clear if this is named something like `significantDigitsNum` or similar? No strong feelings, just confused me a little when I was reading this.

I can see it leading to confusion. I have changed it to `significantDigitsNum`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24295#discussion_r2021131607
PR Review Comment: https://git.openjdk.org/jdk/pull/24295#discussion_r2021131283

From duke at openjdk.org  Fri Apr 11 18:41:40 2025
From: duke at openjdk.org (Johannes Graham)
Date: Fri, 11 Apr 2025 18:41:40 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number
In-Reply-To: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
Message-ID: <d7lgKo5ZbCEV_m4UZWVz6EBlkqwOKFsJGkMwLI_8KpM=.873af43a-454b-4177-b481-d260d1415537@github.com>

On Fri, 28 Mar 2025 15:19:46 GMT, Rohitash <duke at openjdk.org> wrote:

> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
> 
> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
> 
> I benchmarked on local machine for potential regressions.
> https://gist.github.com/rk-kmr/cb1a3d59225c17b180a29cc125ebf887
> 
> 
> Benchmark                                     Mode     Cnt        Score       Error   Units
> URIBenchMark.newImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.newImplWithNumberlUrl           thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNumUrl               thrpt      10        0.001 ?     0.001  ops/ns
> URIBenchMark.newImplWithNormalUrl             avgt      10      236.762 ?     8.700   ns/op
> URIBenchMark.newImplWithNumberlUrl            avgt      10      264.017 ?     7.274   ns/op
> URIBenchMark.oldImplWithNormalUrl             avgt      10      233.853 ?     6.539   ns/op
> URIBenchMark.oldImplWithNumUrl                avgt      10     1183.572 ?    29.242   ns/op
> 
> 
> I ran following tests.
> 
> make test-tier1
> make test-tier2
> make test TEST=jdk/java/net

src/java.base/share/classes/java/net/URI.java line 3438:

> 3436: 
> 3437:             // If no significant digits (all zeros), the value is 0
> 3438:             if (significantDigitsNum == 0)  return q;

Can avoid parseInt for short strings
Suggestion:

            if (significantDigitsNum < 3)  return q; // definitely < 255

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24295#discussion_r2027378782

From alanb at openjdk.org  Sat Apr 12 06:09:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 12 Apr 2025 06:09:30 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number
In-Reply-To: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
Message-ID: <TEDiKpQktKAJ7aab7X6jIJRBEOhh3Kb1dPbJyOAfBVk=.35f73e36-c934-417d-9d52-b09890a55b6f@github.com>

On Fri, 28 Mar 2025 15:19:46 GMT, Rohitash <duke at openjdk.org> wrote:

> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
> 
> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
> 
> I benchmarked on local machine for potential regressions.
> https://gist.github.com/rk-kmr/cb1a3d59225c17b180a29cc125ebf887
> 
> 
> Benchmark                                     Mode     Cnt        Score       Error   Units
> URIBenchMark.newImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.newImplWithNumberlUrl           thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNumUrl               thrpt      10        0.001 ?     0.001  ops/ns
> URIBenchMark.newImplWithNormalUrl             avgt      10      236.762 ?     8.700   ns/op
> URIBenchMark.newImplWithNumberlUrl            avgt      10      264.017 ?     7.274   ns/op
> URIBenchMark.oldImplWithNormalUrl             avgt      10      233.853 ?     6.539   ns/op
> URIBenchMark.oldImplWithNumUrl                avgt      10     1183.572 ?    29.242   ns/op
> 
> 
> I ran following tests.
> 
> make test-tier1
> make test-tier2
> make test TEST=jdk/java/net

test/jdk/java/net/URI/Test.java line 1791:

> 1789: 
> 1790:     // 8353013 - java.net.URI.create(String) may have low performance to scan the host/domain name from
> 1791:     //           URI string when the hostname starts with number

This comment looks a bit out of place in a unit test. I think start with a JMH benchmark and change the comment here to make it clearer that it's provide more test coverage for case the authority component of a hierarchical when the host component starts with a number.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24295#discussion_r2040578232

From dfuchs at openjdk.org  Mon Apr 14 12:53:19 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 14 Apr 2025 12:53:19 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number
In-Reply-To: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
Message-ID: <o4UWJW9kPSVh3ICEUmZ-e8iVC3mY5tfoYQrurMXGDNc=.7e3a9d49-0e7d-4d01-937b-04553cd1bab8@github.com>

On Fri, 28 Mar 2025 15:19:46 GMT, Rohitash <duke at openjdk.org> wrote:

> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
> 
> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
> 
> I benchmarked on local machine for potential regressions.
> https://gist.github.com/rk-kmr/cb1a3d59225c17b180a29cc125ebf887
> 
> 
> Benchmark                                     Mode     Cnt        Score       Error   Units
> URIBenchMark.newImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.newImplWithNumberlUrl           thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNumUrl               thrpt      10        0.001 ?     0.001  ops/ns
> URIBenchMark.newImplWithNormalUrl             avgt      10      236.762 ?     8.700   ns/op
> URIBenchMark.newImplWithNumberlUrl            avgt      10      264.017 ?     7.274   ns/op
> URIBenchMark.oldImplWithNormalUrl             avgt      10      233.853 ?     6.539   ns/op
> URIBenchMark.oldImplWithNumUrl                avgt      10     1183.572 ?    29.242   ns/op
> 
> 
> I ran following tests.
> 
> make test-tier1
> make test-tier2
> make test TEST=jdk/java/net

test/jdk/java/net/URI/Test.java line 1809:

> 1807:         testCreate("https://123.example.com").s("https").h("123.example.com").p("").z();
> 1808:         testCreate("https://1234.example.com").s("https").h("1234.example.com").p("").z();
> 1809:         testCreate("https://12345.example.com").s("https").h("12345.example.com").p("").z();

can we add some URIs similar to the offending URI here? Something like: 

https://98765432101.www.example.com/ and "https://9223372036854775808.www.example.com/"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24295#discussion_r2042014142

From michaelm at openjdk.org  Mon Apr 14 12:55:16 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 14 Apr 2025 12:55:16 GMT
Subject: RFR: 8351339: WebSocket::sendBinary assume that user supplied
 buffers are BIG_ENDIAN [v8]
In-Reply-To: <u-GM635NAS-VswbJCA3JpTeeY7GDLY-HStqqDS9HiUM=.9a4948c1-d94e-4fda-9dc8-143af4846446@github.com>
References: <DZNj1tQz990jOnUOIoik2387TGm8btL_IE1UfGHa1PU=.b039c500-6a30-4757-83f4-7825ea86c3a7@github.com>
 <u-GM635NAS-VswbJCA3JpTeeY7GDLY-HStqqDS9HiUM=.9a4948c1-d94e-4fda-9dc8-143af4846446@github.com>
Message-ID: <sdGogn3r6k4fTm6eZUyY4sNLOiLDZFV0iPA82R9xxYY=.171f03e1-d99d-4a97-8719-7924fedaf056@github.com>

On Fri, 4 Apr 2025 10:44:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Fixes endian handling `jdk.internal.net.http.websocket.Frame.Masker`.
>> 
>> ### Implementation notes
>> 
>> I deleted the `Frame` clone in tests, and rewired the test code depending on it to the actual `Frame`. To enable this, I relaxed the visibility of the actual `Frame`. I guess the `Frame` clone was introduced to have strict visibility in the actual `Frame`. Though this is not needed since the actual `Frame` is in an internal package. Plus, the fact that bug is in the `Frame` class hints in the direction that there should be one `Frame`.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use negative `byte` values in tests

Negative tests look fine.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24033#pullrequestreview-2763928152

From dfuchs at openjdk.org  Mon Apr 14 14:24:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 14 Apr 2025 14:24:51 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
Message-ID: <uCd68Vee5NOCPBEX9OtIf8mdx4-OZzgO3PDWRq1qnNI=.0188887e-bddd-4281-8114-894c0575d07e@github.com>

On Thu, 10 Apr 2025 21:26:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to minimise code changes

src/java.base/share/classes/java/net/NetworkInterface.java line 329:

> 327:         } else {
> 328:             throw new IllegalArgumentException(
> 329:                 formatMsg("invalid address type%s", filterNetInfo(addr.toString()).prefixWith(": ")));

OK - I see that `addr` cannot be null if we reach here.

src/java.base/share/classes/java/net/Proxy.java line 101:

> 99:             throw new IllegalArgumentException(
> 100:                 formatMsg("type " + type + " is not compatible with address %s",
> 101:                           filterNetInfo(sa.toString())

You will get NullPointerException instead of IllegalArgumentException if `sa` is `null`. I suggest using `String.valueOf(sa)` rather than `sa.toString()` to preserve the pre-existing behaviour.

src/java.base/share/classes/java/net/Proxy.java line 102:

> 100:                 formatMsg("type " + type + " is not compatible with address %s",
> 101:                           filterNetInfo(sa.toString())
> 102:                                .replaceWith("type " + sa.getClass().toString())));

You will have to guard against sa == null here

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:

> 251: 
> 252:         int i = 0;
> 253:         boolean enhanced = true;

`enhanced` doesn't seem to be used here. Is this some leftover?

src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java line 203:

> 201:                 throw new NullPointerException(
> 202:                     formatMsg("malformed context url%s : no !/",
> 203:                               filterJarName(url.toString()).prefixWith(": ")));

It's not clear whether `url` could be `null` here, so to sidestep the question maybe use `String::valueOf` rather than `Object::toString`.

src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java line 212:

> 210:                 throw new NullPointerException(
> 211:                     formatMsg("malformed context url%s",
> 212:                               filterJarName(url.toString()).prefixWith(": ")));

Same remark here

test/jdk/java/net/URI/Test.java line 29:

> 27:  *      7171415 6339649 6933879 8037396 8272072 8051627 8297687
> 28:  * @author Mark Reinhold
> 29:  * @run main/othervm -Djdk.includeInExceptions=hostInfo Test

This change does not look like it's needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042182598
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042187411
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042190019
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042199577
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042214144
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042215273
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042244694

From abarashev at openjdk.org  Mon Apr 14 15:19:18 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 14 Apr 2025 15:19:18 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v3]
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <AOg-yiaYmOpPl5RDYFvQg_TnvYB6zh5658vXPzRKdC8=.d8caa239-4db6-45bc-b070-117947d1e579@github.com>

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
> 
> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update Copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24425/files
  - new: https://git.openjdk.org/jdk/pull/24425/files/134a3264..9d2a7743

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=01-02

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From duke at openjdk.org  Mon Apr 14 16:34:21 2025
From: duke at openjdk.org (Rohitash)
Date: Mon, 14 Apr 2025 16:34:21 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number [v2]
In-Reply-To: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
Message-ID: <EI914_05VtAS-OlJsZoCeZALqZRbCve9ly3ZWtvQ-xU=.c6d85a88-25ad-40aa-98b3-f307646d85b8@github.com>

> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
> 
> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
> 
> I benchmarked on local machine for potential regressions.
> https://gist.github.com/rk-kmr/cb1a3d59225c17b180a29cc125ebf887
> 
> 
> Benchmark                                     Mode     Cnt        Score       Error   Units
> URIBenchMark.newImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.newImplWithNumberlUrl           thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNormalUrl            thrpt      10        0.004 ?     0.001  ops/ns
> URIBenchMark.oldImplWithNumUrl               thrpt      10        0.001 ?     0.001  ops/ns
> URIBenchMark.newImplWithNormalUrl             avgt      10      236.762 ?     8.700   ns/op
> URIBenchMark.newImplWithNumberlUrl            avgt      10      264.017 ?     7.274   ns/op
> URIBenchMark.oldImplWithNormalUrl             avgt      10      233.853 ?     6.539   ns/op
> URIBenchMark.oldImplWithNumUrl                avgt      10     1183.572 ?    29.242   ns/op
> 
> 
> I ran following tests.
> 
> make test-tier1
> make test-tier2
> make test TEST=jdk/java/net

Rohitash has updated the pull request incrementally with two additional commits since the last revision:

 - Add benchmark
 - Address PR comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24295/files
  - new: https://git.openjdk.org/jdk/pull/24295/files/4a6c3d6c..07bff288

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24295&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24295&range=00-01

  Stats: 76 lines in 3 files changed: 73 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24295.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24295/head:pull/24295

PR: https://git.openjdk.org/jdk/pull/24295

From duke at openjdk.org  Mon Apr 14 16:37:43 2025
From: duke at openjdk.org (Rohitash)
Date: Mon, 14 Apr 2025 16:37:43 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number [v2]
In-Reply-To: <TEDiKpQktKAJ7aab7X6jIJRBEOhh3Kb1dPbJyOAfBVk=.35f73e36-c934-417d-9d52-b09890a55b6f@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
 <TEDiKpQktKAJ7aab7X6jIJRBEOhh3Kb1dPbJyOAfBVk=.35f73e36-c934-417d-9d52-b09890a55b6f@github.com>
Message-ID: <xopJREqd0YXFMmIn8BHXFJU7Zm10U5IEga_RstmRzdw=.92df1ed2-3f8d-4f02-8e8e-92a54696f25d@github.com>

On Sat, 12 Apr 2025 06:06:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Rohitash has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add benchmark
>>  - Address PR comments
>
> test/jdk/java/net/URI/Test.java line 1791:
> 
>> 1789: 
>> 1790:     // 8353013 - java.net.URI.create(String) may have low performance to scan the host/domain name from
>> 1791:     //           URI string when the hostname starts with number
> 
> This comment looks a bit out of place in a unit test. I think start with a JMH benchmark and change the comment in the unit test to make it clearer that it's providing more test coverage for cases where the authority component of a hierarchical URI has a host component that starts with a number.

Thanks! I have updated the comment and added a JMH benchmark.


## Before
Benchmark                                                    Mode  Cnt     Score    Error  Units
URIAuthorityParsingBenchmark.createUriWithNumericHostPrefix  avgt   15  1555.875 ? 66.857  ns/op
URIAuthorityParsingBenchmark.createUriWithStandardHost       avgt   15   268.101 ?  1.634  ns/op

## After
Benchmark                                                    Mode  Cnt    Score    Error  Units
URIAuthorityParsingBenchmark.createUriWithNumericHostPrefix  avgt   15  381.902 ?  4.821  ns/op
URIAuthorityParsingBenchmark.createUriWithStandardHost       avgt   15  271.377 ? 10.165  ns/op

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24295#discussion_r2042505911

From duke at openjdk.org  Mon Apr 14 16:37:44 2025
From: duke at openjdk.org (Rohitash)
Date: Mon, 14 Apr 2025 16:37:44 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number [v2]
In-Reply-To: <o4UWJW9kPSVh3ICEUmZ-e8iVC3mY5tfoYQrurMXGDNc=.7e3a9d49-0e7d-4d01-937b-04553cd1bab8@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
 <o4UWJW9kPSVh3ICEUmZ-e8iVC3mY5tfoYQrurMXGDNc=.7e3a9d49-0e7d-4d01-937b-04553cd1bab8@github.com>
Message-ID: <iZqHpX64H0gXIUSm_JOmdgt6UM7jriN8JXDuewquXbQ=.e18d9c63-6b5b-48df-a106-4da76c611ac9@github.com>

On Mon, 14 Apr 2025 12:12:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Rohitash has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add benchmark
>>  - Address PR comments
>
> test/jdk/java/net/URI/Test.java line 1809:
> 
>> 1807:         testCreate("https://123.example.com").s("https").h("123.example.com").p("").z();
>> 1808:         testCreate("https://1234.example.com").s("https").h("1234.example.com").p("").z();
>> 1809:         testCreate("https://12345.example.com").s("https").h("12345.example.com").p("").z();
> 
> can we add some URIs similar to the offending URI here? Something like: 
> 
> https://98765432101.www.example.com/ and "https://9223372036854775808.www.example.com/"

Thanks! I have added more examples.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24295#discussion_r2042506649

From vyazici at openjdk.org  Mon Apr 14 19:18:51 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 14 Apr 2025 19:18:51 GMT
Subject: Integrated: 8351339: WebSocket::sendBinary assume that user supplied
 buffers are BIG_ENDIAN
In-Reply-To: <DZNj1tQz990jOnUOIoik2387TGm8btL_IE1UfGHa1PU=.b039c500-6a30-4757-83f4-7825ea86c3a7@github.com>
References: <DZNj1tQz990jOnUOIoik2387TGm8btL_IE1UfGHa1PU=.b039c500-6a30-4757-83f4-7825ea86c3a7@github.com>
Message-ID: <RBi7B2e2HUVUe73g8Q0Nh6UFCdSiSgYKeyTAt_B83pE=.a97daf3f-cc18-431b-9fe2-adbe24d22095@github.com>

On Thu, 13 Mar 2025 13:34:04 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Fixes endian handling `jdk.internal.net.http.websocket.Frame.Masker`.
> 
> ### Implementation notes
> 
> I deleted the `Frame` clone in tests, and rewired the test code depending on it to the actual `Frame`. To enable this, I relaxed the visibility of the actual `Frame`. I guess the `Frame` clone was introduced to have strict visibility in the actual `Frame`. Though this is not needed since the actual `Frame` is in an internal package. Plus, the fact that bug is in the `Frame` class hints in the direction that there should be one `Frame`.

This pull request has now been integrated.

Changeset: f6d8c8cb
Author:    Volkan Yazici <vyazici at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6d8c8cb0c6b226d68791ffd126908d3fea11473
Stats:     943 lines in 11 files changed: 288 ins; 584 del; 71 mod

8351339: WebSocket::sendBinary assume that user supplied buffers are BIG_ENDIAN

Reviewed-by: michaelm, dfuchs

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

PR: https://git.openjdk.org/jdk/pull/24033

From duke at openjdk.org  Mon Apr 14 19:49:41 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Mon, 14 Apr 2025 19:49:41 GMT
Subject: RFR: 8353453: URLDecoder should use HexFormat
In-Reply-To: <pmET5pBFBPd39LQzFclTuexDz-2UUsiH9F_gSeSpUCU=.fc24048d-9b7e-43e0-9a89-35f45d651cd7@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
 <pmET5pBFBPd39LQzFclTuexDz-2UUsiH9F_gSeSpUCU=.fc24048d-9b7e-43e0-9a89-35f45d651cd7@github.com>
Message-ID: <nkPG4ih7IwiTXRMPZWTbyOordquQwTz-SQT5fKga1MI=.d8487747-e337-4579-b7cd-b1eda109b4d0@github.com>

On Mon, 7 Apr 2025 09:55:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.
>
> Tests came back green - a few unrelated failures.

@dfuch @jaikiran @RogerRiggs Thank you for taking a look at this PR; looks like I need a sponsor. Would any of you be willing to sponsor this change?

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

PR Comment: https://git.openjdk.org/jdk/pull/24314#issuecomment-2802826628

From vyazici at openjdk.org  Tue Apr 15 07:26:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Apr 2025 07:26:33 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v13]
In-Reply-To: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
Message-ID: <lKKwsbJEoefulOPCW8v6ICzpxlQtA4T-53uO6X8Z418=.dceaaf75-a981-4400-a119-c91be39460c4@github.com>

> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
> 
> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Replace FJP usage with a dedicated executor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24154/files
  - new: https://git.openjdk.org/jdk/pull/24154/files/a1bb8cf0..a0859c7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=11-12

  Stats: 359 lines in 2 files changed: 291 ins; 43 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/24154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24154/head:pull/24154

PR: https://git.openjdk.org/jdk/pull/24154

From vyazici at openjdk.org  Tue Apr 15 07:29:47 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Apr 2025 07:29:47 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v12]
In-Reply-To: <kaVeZSOWOn_GZk-TMbcAtPxByL3K2FH3hjuKGnVvAYY=.b3a5fe5f-f9dc-4746-a8b2-19edec724eb9@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
 <D8jiIFBf62wV8I9K6Ec6LXQ08D1gsCxcDrfLZGJIbpw=.bcae452f-80ef-4856-8420-a30aad7dc439@github.com>
 <kaVeZSOWOn_GZk-TMbcAtPxByL3K2FH3hjuKGnVvAYY=.b3a5fe5f-f9dc-4746-a8b2-19edec724eb9@github.com>
Message-ID: <TCbsz-mm5pAGiCxBe8v8UKMKomJnUTXFyg5krvUmTBc=.b4a77a5d-d9a0-4309-8e16-e3c4da0de94a@github.com>

On Thu, 10 Apr 2025 13:58:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 129:
>> 
>>> 127:                 throw new RuntimeException("failed closing server", serverException);
>>> 128:             }
>>> 129:         }
>> 
>> The message here seems to be wrong. Can we use something less exotic to start the server too, and start it, for instance in the calling code?
>
> And also maybe log something after it's started - including the server authority where it's listening at?

Both are implemented in a0859c7c68614e8c3f531b1d4d9357f3f48cf5ab.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2043840499

From vyazici at openjdk.org  Tue Apr 15 07:29:49 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Apr 2025 07:29:49 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v12]
In-Reply-To: <fpuI8-_OQIxav50T3SZeY9Ne01X3w-zQzUPit4c9dUY=.61f33c67-02fb-4b67-bf2a-9d2c409bff57@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
 <fpuI8-_OQIxav50T3SZeY9Ne01X3w-zQzUPit4c9dUY=.61f33c67-02fb-4b67-bf2a-9d2c409bff57@github.com>
Message-ID: <tbUegFsAWFSzyTYD21UCqy4NQ-Wo-jGVwxgp3bX6kkA=.f0c1649b-a64d-470c-a828-1995e0da5f6d@github.com>

On Thu, 10 Apr 2025 13:56:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add `@implNote` to state that the built-in is always non-empty
>
> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 171:
> 
>> 169:                             String message = "Server[%s] has failed! (connectionKey=%s, responseBody=%s)"
>> 170:                                     .formatted(serverId, connectionKey, responseBody);
>> 171:                             throw new RuntimeException(message, ioe);
> 
> I would recommend logging something here before throwing the exception. For instance calling `ioe.printStackTrace()`. There's not supposed to be one, and if there  is one it's not guaranteed that throwing it will ensure that it gets logged. The client might fail with some other error, or the test may timeout, and we will never know what happened.

Implemented to both log and throw in a0859c7c68614e8c3f531b1d4d9357f3f48cf5ab.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2043842705

From vyazici at openjdk.org  Tue Apr 15 07:33:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Apr 2025 07:33:58 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v12]
In-Reply-To: <9BJz90SgBd5cbCY4q8hShnY6x7vRnX2wYl1zmAKzSvo=.239ec904-1255-4e5b-90ce-704ad2307f86@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
 <PWwYkZOw9hBPnhq5fOJ83VvTeGOf8Tk80MeGtpfLK_M=.ead3599a-854d-474a-8f6c-026c22c38afc@github.com>
 <9BJz90SgBd5cbCY4q8hShnY6x7vRnX2wYl1zmAKzSvo=.239ec904-1255-4e5b-90ce-704ad2307f86@github.com>
Message-ID: <x6eLfSgP0sJK9rAGTh1vGqiNux1RjYasjxQ_xHd6J3E=.31f53c37-cdf8-4b41-9d04-8c0c466e6ab5@github.com>

On Fri, 11 Apr 2025 18:05:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 188:
>> 
>>> 186:         private static HttpTestServer createServer(Version version, SSLContext sslContext) {
>>> 187:             try {
>>> 188:                 return HttpTestServer.create(version, sslContext, ForkJoinPool.commonPool());
>> 
>> OK - we definitely MUST NOT use the common FJP here. 
>> 
>> 1. our HTTP/2 servers start their dispatching thread, which blocks on accept(), in the executor. 
>> 2. the tests will block (CountDownLatch) in the exchange, which is a thread in the executor.
>> 3. the test creates at least two HTTP/2 servers (maybe more) upfront.
>> 
>> If you run this test on a machine that has a low number of processors - say 4 - then the FJP will maybe have 3 threads at most. You can see where that goes...
>
> If no executor is provided the HTTP/2 server will create its own. The HTTP/1.1 server however will run the exchange in the dispacher thread - so you need to at least provide an executor for the HTTP/1.1 server if you don't want to wedge when making parallel requests. But not the common FJP ;-)

In a0859c7c68614e8c3f531b1d4d9357f3f48cf5ab,

- Used a dedicated executor (!= FJP) only for HTTP/1.1 servers (also documented the rationale in the sources)
- Added `SystemDiagnosticsCollector` to aid with troubleshooting

Verified that test passes on Windows, Linux, and macOS hosts with 30 repetitions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2043850831

From jpai at openjdk.org  Tue Apr 15 09:03:24 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 15 Apr 2025 09:03:24 GMT
Subject: RFR: 8354576: InetAddress.getLocalHost() on macos may return address
 of an interface which is not UP - leading to "Network is down" error
Message-ID: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>

Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8354576?

As noted in that issue, the current code in the `lookupAllHostAddr()` function of `Inet4AddressImpl.c` and `Inet6AddressImpl.c` has a macos specific implementation, where we call `getifaddrs()` and iterate over the returned addresses. In its current form this code doesn't check to see if the interface is UP or not. This can result in returing an address belonging to an interface which is not UP. That can cause subsequent usage of the address for networking operations to result in a "Network is down" error.

The commit in this PR skips interfaces that are not UP. The change only impacts the result of `getLocalHost()` call and that too only on macos. Given the nature of this change no new regression test has been introduced. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

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

Commit messages:
 - 8354576: InetAddress.getLocalHost() on macos may return address of an interface which is not UP - leading to "Network is down" error

Changes: https://git.openjdk.org/jdk/pull/24653/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24653&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354576
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24653/head:pull/24653

PR: https://git.openjdk.org/jdk/pull/24653

From vyazici at openjdk.org  Tue Apr 15 09:28:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Apr 2025 09:28:05 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v12]
In-Reply-To: <x6eLfSgP0sJK9rAGTh1vGqiNux1RjYasjxQ_xHd6J3E=.31f53c37-cdf8-4b41-9d04-8c0c466e6ab5@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <Bp-iCvRTteC_-uao_VrGibKDLYayk6ekg8TKiimX6do=.51788984-9f86-4582-b299-5029d216103e@github.com>
 <PWwYkZOw9hBPnhq5fOJ83VvTeGOf8Tk80MeGtpfLK_M=.ead3599a-854d-474a-8f6c-026c22c38afc@github.com>
 <9BJz90SgBd5cbCY4q8hShnY6x7vRnX2wYl1zmAKzSvo=.239ec904-1255-4e5b-90ce-704ad2307f86@github.com>
 <x6eLfSgP0sJK9rAGTh1vGqiNux1RjYasjxQ_xHd6J3E=.31f53c37-cdf8-4b41-9d04-8c0c466e6ab5@github.com>
Message-ID: <JFFS9kKvNZwtiNMSWsj1CBIuhGNVEdCHfEjTTk7usXk=.aa43a3b9-475f-4643-aa6a-a05ad7df0749@github.com>

On Tue, 15 Apr 2025 07:31:32 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> If no executor is provided the HTTP/2 server will create its own. The HTTP/1.1 server however will run the exchange in the dispacher thread - so you need to at least provide an executor for the HTTP/1.1 server if you don't want to wedge when making parallel requests. But not the common FJP ;-)
>
> In a0859c7c68614e8c3f531b1d4d9357f3f48cf5ab,
> 
> - Used a dedicated executor (!= FJP) only for HTTP/1.1 servers (also documented the rationale in the sources)
> - Added `SystemDiagnosticsCollector` to aid with troubleshooting
> 
> Verified that test passes on Windows, Linux, and macOS hosts with 30 repetitions.

After consulting @jaikiran, removed `SystemDiagnosticsCollector` in ad73d38cd0382308224f721722367fd289fdc9d5. I will separately explore the possibilities of adding a similar troubleshooting tool in a more generic fashion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24154#discussion_r2044086645

From vyazici at openjdk.org  Tue Apr 15 09:28:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Apr 2025 09:28:05 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v14]
In-Reply-To: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
Message-ID: <fH_VeIoV4Ss1yHrLYCrbPA7SiCiII1vMniEyYnv6yzg=.563fc4ad-fd63-4a2f-bd56-3ef40d87cc5c@github.com>

> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
> 
> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Remove `SystemDiagnosticsCollector`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24154/files
  - new: https://git.openjdk.org/jdk/pull/24154/files/a0859c7c..ad73d38c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24154&range=12-13

  Stats: 202 lines in 2 files changed: 0 ins; 201 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24154/head:pull/24154

PR: https://git.openjdk.org/jdk/pull/24154

From dfuchs at openjdk.org  Tue Apr 15 09:56:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Apr 2025 09:56:55 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v14]
In-Reply-To: <fH_VeIoV4Ss1yHrLYCrbPA7SiCiII1vMniEyYnv6yzg=.563fc4ad-fd63-4a2f-bd56-3ef40d87cc5c@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <fH_VeIoV4Ss1yHrLYCrbPA7SiCiII1vMniEyYnv6yzg=.563fc4ad-fd63-4a2f-bd56-3ef40d87cc5c@github.com>
Message-ID: <Hcp3iBDpXTR2gghf00TXm86akUobdezBsLeTHl3uZNY=.55cb5a97-401e-4398-ac09-3befefe49d71@github.com>

On Tue, 15 Apr 2025 09:28:05 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `SystemDiagnosticsCollector`

LGTM.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24154#pullrequestreview-2767629832

From alanb at openjdk.org  Tue Apr 15 10:05:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Apr 2025 10:05:55 GMT
Subject: RFR: 8354576: InetAddress.getLocalHost() on macos may return
 address of an interface which is not UP - leading to "Network is down" error
In-Reply-To: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
References: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
Message-ID: <7O_Xo1Bm-MVzbl5iDTudBdjtAwbuEb6GbtBcgmGqUhU=.0f204487-4c30-484e-a148-566190038e1d@github.com>

On Tue, 15 Apr 2025 08:58:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8354576?
> 
> As noted in that issue, the current code in the `lookupAllHostAddr()` function of `Inet4AddressImpl.c` and `Inet6AddressImpl.c` has a macos specific implementation, where we call `getifaddrs()` and iterate over the returned addresses. In its current form this code doesn't check to see if the interface is UP or not. This can result in returing an address belonging to an interface which is not UP. That can cause subsequent usage of the address for networking operations to result in a "Network is down" error.
> 
> The commit in this PR skips interfaces that are not UP. The change only impacts the result of `getLocalHost()` call and that too only on macos. Given the nature of this change no new regression test has been introduced. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24653#pullrequestreview-2767654956

From michaelm at openjdk.org  Tue Apr 15 11:10:49 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 15 Apr 2025 11:10:49 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: <uCd68Vee5NOCPBEX9OtIf8mdx4-OZzgO3PDWRq1qnNI=.0188887e-bddd-4281-8114-894c0575d07e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
 <uCd68Vee5NOCPBEX9OtIf8mdx4-OZzgO3PDWRq1qnNI=.0188887e-bddd-4281-8114-894c0575d07e@github.com>
Message-ID: <4T-aEuL5RC4ragkopv7afbUBA3NT9efLxcG6EZGCJ8o=.65b066df-bc22-4df5-a7b8-c09b8e7515f7@github.com>

On Mon, 14 Apr 2025 13:51:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to minimise code changes
>
> src/java.base/share/classes/java/net/Proxy.java line 102:
> 
>> 100:                 formatMsg("type " + type + " is not compatible with address %s",
>> 101:                           filterNetInfo(sa.toString())
>> 102:                                .replaceWith("type " + sa.getClass().toString())));
> 
> You will have to guard against sa == null here

The `replaceWith()` call is actually not needed at all. I will remove it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2044273655

From michaelm at openjdk.org  Tue Apr 15 11:24:47 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 15 Apr 2025 11:24:47 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: <uCd68Vee5NOCPBEX9OtIf8mdx4-OZzgO3PDWRq1qnNI=.0188887e-bddd-4281-8114-894c0575d07e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
 <uCd68Vee5NOCPBEX9OtIf8mdx4-OZzgO3PDWRq1qnNI=.0188887e-bddd-4281-8114-894c0575d07e@github.com>
Message-ID: <5ovW0BNN592wq1AFeHxH0QsrKk-hDXqCtGHgwRJ6StU=.ab9fa83f-27a7-485f-b586-4b1572329694@github.com>

On Mon, 14 Apr 2025 14:20:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to minimise code changes
>
> test/jdk/java/net/URI/Test.java line 29:
> 
>> 27:  *      7171415 6339649 6933879 8037396 8272072 8051627 8297687
>> 28:  * @author Mark Reinhold
>> 29:  * @run main/othervm -Djdk.includeInExceptions=hostInfo Test
> 
> This change does not look like it's needed.

Thanks for the review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2044297016

From duke at openjdk.org  Tue Apr 15 11:29:47 2025
From: duke at openjdk.org (Patrick Strawderman)
Date: Tue, 15 Apr 2025 11:29:47 GMT
Subject: Integrated: 8353453: URLDecoder should use HexFormat
In-Reply-To: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
References: <BMRqZQyAQjiJTHz-_HNjEDAo-e3BF_PL3QAg1wRR5lQ=.fb318fc4-3984-4e60-a532-7451db18c27f@github.com>
Message-ID: <-mcNsE_255_IUraWIprmAes8duuwzoAJl1xZBLHkRgw=.184c7893-90b4-452f-acc0-a378465034a3@github.com>

On Sat, 29 Mar 2025 17:27:20 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.

This pull request has now been integrated.

Changeset: 03fd43fc
Author:    Patrick Strawderman <pstrawderman at netflix.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03fd43fc91ea383418c1c7e0fd96a61a1f42c75e
Stats:     6 lines in 1 file changed: 1 ins; 4 del; 1 mod

8353453: URLDecoder should use HexFormat

Reviewed-by: rriggs, jpai

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

PR: https://git.openjdk.org/jdk/pull/24314

From duke at openjdk.org  Tue Apr 15 11:31:46 2025
From: duke at openjdk.org (duke)
Date: Tue, 15 Apr 2025 11:31:46 GMT
Subject: RFR: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections [v14]
In-Reply-To: <fH_VeIoV4Ss1yHrLYCrbPA7SiCiII1vMniEyYnv6yzg=.563fc4ad-fd63-4a2f-bd56-3ef40d87cc5c@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
 <fH_VeIoV4Ss1yHrLYCrbPA7SiCiII1vMniEyYnv6yzg=.563fc4ad-fd63-4a2f-bd56-3ef40d87cc5c@github.com>
Message-ID: <oG30sFrjsBDKcjCg7xrvxSSJA-1HU2w9HsQyTfv5JD4=.6979ed84-a8d9-4ddc-b2f2-858eb22e25cb@github.com>

On Tue, 15 Apr 2025 09:28:05 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
>> 
>> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `SystemDiagnosticsCollector`

@vy 
Your change (at version ad73d38cd0382308224f721722367fd289fdc9d5) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24154#issuecomment-2804731547

From vyazici at openjdk.org  Tue Apr 15 11:44:50 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Apr 2025 11:44:50 GMT
Subject: Integrated: 8350279: HttpClient: Add a new HttpResponse method to
 identify connections
In-Reply-To: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
References: <DxMw0JYA8n4FgO82H9JU_s_hwrBgFEWRb3JHz1INMv4=.7e68e03d-6cc8-4fef-82a0-8a608390e8ce@github.com>
Message-ID: <YPlOFmia6wrn-PyF2uIEdyt5JqhRGqS618q4NLIIpt8=.707a750d-c50c-49d1-b10c-2d16a8f9c758@github.com>

On Fri, 21 Mar 2025 13:45:24 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Adds `HttpResponse::connectionLabel` method that provides an identifier for the connection.
> 
> **Implementation note:** The feature is facilitated by `HttpConnection::label`, which should not be confused with `HttpConnection::id`. This distinction is explained in the JavaDoc of both properties.

This pull request has now been integrated.

Changeset: 5fc18f5b
Author:    Volkan Yazici <vyazici at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5fc18f5b8aa1b5f4fb4313b8d11fd15330795959
Stats:     602 lines in 12 files changed: 567 ins; 2 del; 33 mod

8350279: HttpClient: Add a new HttpResponse method to identify connections

Reviewed-by: dfuchs, jpai

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

PR: https://git.openjdk.org/jdk/pull/24154

From dfuchs at openjdk.org  Tue Apr 15 13:25:48 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Apr 2025 13:25:48 GMT
Subject: RFR: 8354576: InetAddress.getLocalHost() on macos may return
 address of an interface which is not UP - leading to "Network is down" error
In-Reply-To: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
References: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
Message-ID: <PghmD7bV4rD43iKfrrFXB7EtUQcofT0ff2uH5HLkAcU=.25d3afaa-02e3-4dc0-80be-64fb97d99aaf@github.com>

On Tue, 15 Apr 2025 08:58:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8354576?
> 
> As noted in that issue, the current code in the `lookupAllHostAddr()` function of `Inet4AddressImpl.c` and `Inet6AddressImpl.c` has a macos specific implementation, where we call `getifaddrs()` and iterate over the returned addresses. In its current form this code doesn't check to see if the interface is UP or not. This can result in returing an address belonging to an interface which is not UP. That can cause subsequent usage of the address for networking operations to result in a "Network is down" error.
> 
> The commit in this PR skips interfaces that are not UP. The change only impacts the result of `getLocalHost()` call and that too only on macos. Given the nature of this change no new regression test has been introduced. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

Look reasonable to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24653#pullrequestreview-2768259475

From michaelm at openjdk.org  Tue Apr 15 14:35:28 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 15 Apr 2025 14:35:28 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v6]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - doc + copyright update
 - remove file added by mistake
 - whitespace
 - moved test
 - ... and 10 more: https://git.openjdk.org/jdk/compare/b7837843...da33863c

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=05
  Stats: 948 lines in 42 files changed: 715 ins; 101 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From mullan at openjdk.org  Tue Apr 15 14:50:01 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Apr 2025 14:50:01 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v3]
In-Reply-To: <AOg-yiaYmOpPl5RDYFvQg_TnvYB6zh5658vXPzRKdC8=.d8caa239-4db6-45bc-b070-117947d1e579@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
 <AOg-yiaYmOpPl5RDYFvQg_TnvYB6zh5658vXPzRKdC8=.d8caa239-4db6-45bc-b070-117947d1e579@github.com>
Message-ID: <w18JJHc5sWPBgJWLf5HItI0nZgEt1wGT-RIyD-EGjU8=.5eb12a86-ad34-45f0-b0fd-397a5a7a9db7@github.com>

On Mon, 14 Apr 2025 15:19:18 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>> 
>> 
>> Any endpoint receiving any certificate which it would need to
>> validate using any signature algorithm using an MD5 hash MUST abort
>> the handshake with a "bad_certificate" alert.
>> 
>> 
>> 
>> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
>> 
>> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
>> 
>> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright

test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 57:

> 55:     // Certificates and keys used in the test.
> 56:     // Certificates are signed with signature using MD5WithRSA algorithm.
> 57:     static String trusedCertStr =

We try to avoid hard-coding certificates in tests - can you create these certs as part of a test setup using keytool instead?

test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 270:

> 268:         // MD5 is disabled by default in java.security config file.
> 269:         Security.setProperty("jdk.certpath.disabledAlgorithms", "");
> 270:         Security.setProperty("jdk.tls.disabledAlgorithms", "");

Use `SecurityUtils.removeFromDisabledAlgs` and only remove MD5 from these properties.

test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 304:

> 302:     }
> 303: 
> 304:     private static SSLContext getSSLContext(String trusedCertStr,

Typo: s/trusedCertStr/trustedCertStr/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2044749198
PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2044759691
PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2044772389

From dfuchs at openjdk.org  Tue Apr 15 15:08:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Apr 2025 15:08:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v6]
In-Reply-To: <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com>
Message-ID: <Z3Ao6frnA2TZMU05fCAUC_tCOdGf9jtA3VO-8_6L8qY=.c314bc04-70fd-4986-8c6d-359c6e8a1764@github.com>

On Tue, 15 Apr 2025 14:35:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - update to minimise code changes
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    from turbanoff review
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - doc + copyright update
>  - remove file added by mistake
>  - whitespace
>  - moved test
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/b7837843...da33863c

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2768796475

From abarashev at openjdk.org  Tue Apr 15 15:34:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 15 Apr 2025 15:34:51 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v3]
In-Reply-To: <w18JJHc5sWPBgJWLf5HItI0nZgEt1wGT-RIyD-EGjU8=.5eb12a86-ad34-45f0-b0fd-397a5a7a9db7@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
 <AOg-yiaYmOpPl5RDYFvQg_TnvYB6zh5658vXPzRKdC8=.d8caa239-4db6-45bc-b070-117947d1e579@github.com>
 <w18JJHc5sWPBgJWLf5HItI0nZgEt1wGT-RIyD-EGjU8=.5eb12a86-ad34-45f0-b0fd-397a5a7a9db7@github.com>
Message-ID: <AquXyNcIMpJ591TQcR0EV0JrwNHgXM_E9Sv2qbMc0Io=.3d7f07dd-3237-4309-a5e2-3a10c53bb40a@github.com>

On Tue, 15 Apr 2025 14:35:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Copyright
>
> test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 304:
> 
>> 302:     }
>> 303: 
>> 304:     private static SSLContext getSSLContext(String trusedCertStr,
> 
> Typo: s/trusedCertStr/trustedCertStr/

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2044918762

From eirbjo at openjdk.org  Tue Apr 15 15:36:40 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 15 Apr 2025 15:36:40 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by default
Message-ID: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>

Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.

Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.

This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html

See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.

This PR:

* Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
* Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
* Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
* Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.

I have added a Release Note as a subtask in the JBS issue, this also needs a review.

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

Commit messages:
 - Disable non-local file URLs by default

Changes: https://git.openjdk.org/jdk/pull/24657/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353440
  Stats: 89 lines in 5 files changed: 87 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From abarashev at openjdk.org  Tue Apr 15 16:04:54 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 15 Apr 2025 16:04:54 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v3]
In-Reply-To: <w18JJHc5sWPBgJWLf5HItI0nZgEt1wGT-RIyD-EGjU8=.5eb12a86-ad34-45f0-b0fd-397a5a7a9db7@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
 <AOg-yiaYmOpPl5RDYFvQg_TnvYB6zh5658vXPzRKdC8=.d8caa239-4db6-45bc-b070-117947d1e579@github.com>
 <w18JJHc5sWPBgJWLf5HItI0nZgEt1wGT-RIyD-EGjU8=.5eb12a86-ad34-45f0-b0fd-397a5a7a9db7@github.com>
Message-ID: <E4XynbMDRsKXDRKxCgoxs1dPQfCmwUQwqrce1BXud64=.f59fecf8-368d-404e-b34f-eb736b4772b4@github.com>

On Tue, 15 Apr 2025 14:32:47 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Copyright
>
> test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 270:
> 
>> 268:         // MD5 is disabled by default in java.security config file.
>> 269:         Security.setProperty("jdk.certpath.disabledAlgorithms", "");
>> 270:         Security.setProperty("jdk.tls.disabledAlgorithms", "");
> 
> Use `SecurityUtils.removeFromDisabledAlgs` and only remove MD5 from these properties.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2044980058

From abarashev at openjdk.org  Tue Apr 15 16:10:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 15 Apr 2025 16:10:46 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v4]
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <11-V1fB3JOWQMiMuT6ahw_CNwz3XOVMp2zrm9kdNHuc=.9ba19223-4fed-432e-8892-bf18f08339a7@github.com>

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
> 
> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Only remove MD5 from config properties. Fix a typo.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24425/files
  - new: https://git.openjdk.org/jdk/pull/24425/files/9d2a7743..7a7bb00f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=02-03

  Stats: 16 lines in 1 file changed: 4 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From abarashev at openjdk.org  Tue Apr 15 17:51:34 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 15 Apr 2025 17:51:34 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v5]
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <ajrxMX7qrKqsKQjnjSdP8b93JFbD7Yd5Gv6IgR6-7-s=.5887df78-47c5-46ee-b946-a8712624d4af@github.com>

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
> 
> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Replace hard-coded certs with dynamically generated ones

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24425/files
  - new: https://git.openjdk.org/jdk/pull/24425/files/7a7bb00f..86874f33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=03-04

  Stats: 335 lines in 1 file changed: 92 ins; 225 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From abarashev at openjdk.org  Tue Apr 15 17:51:36 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 15 Apr 2025 17:51:36 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v3]
In-Reply-To: <w18JJHc5sWPBgJWLf5HItI0nZgEt1wGT-RIyD-EGjU8=.5eb12a86-ad34-45f0-b0fd-397a5a7a9db7@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
 <AOg-yiaYmOpPl5RDYFvQg_TnvYB6zh5658vXPzRKdC8=.d8caa239-4db6-45bc-b070-117947d1e579@github.com>
 <w18JJHc5sWPBgJWLf5HItI0nZgEt1wGT-RIyD-EGjU8=.5eb12a86-ad34-45f0-b0fd-397a5a7a9db7@github.com>
Message-ID: <XOS_cg1VTLO8hLE4r5tga-dUHBLjXcXGYM1F8hCf9iM=.f854c15f-fda4-49a2-a542-e37c9ce5b3f6@github.com>

On Tue, 15 Apr 2025 14:30:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Copyright
>
> test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 57:
> 
>> 55:     // Certificates and keys used in the test.
>> 56:     // Certificates are signed with signature using MD5WithRSA algorithm.
>> 57:     static String trusedCertStr =
> 
> We try to avoid hard-coding certificates in tests - can you create these certs as part of a test setup using keytool instead?

Done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2045163151

From vyazici at openjdk.org  Tue Apr 15 18:51:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Apr 2025 18:51:46 GMT
Subject: RFR: 8354576: InetAddress.getLocalHost() on macos may return
 address of an interface which is not UP - leading to "Network is down" error
In-Reply-To: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
References: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
Message-ID: <loSpRhXebmkhUkWCIYDcMATveeC_AjE7LnNQ06vy6Zw=.c37f1056-b988-476f-b033-4f3496905674@github.com>

On Tue, 15 Apr 2025 08:58:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8354576?
> 
> As noted in that issue, the current code in the `lookupAllHostAddr()` function of `Inet4AddressImpl.c` and `Inet6AddressImpl.c` has a macos specific implementation, where we call `getifaddrs()` and iterate over the returned addresses. In its current form this code doesn't check to see if the interface is UP or not. This can result in returing an address belonging to an interface which is not UP. That can cause subsequent usage of the address for networking operations to result in a "Network is down" error.
> 
> The commit in this PR skips interfaces that are not UP. The change only impacts the result of `getLocalHost()` call and that too only on macos. Given the nature of this change no new regression test has been introduced. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

@jaikiran, maybe asking the obvious but... We don't need this `IFF_UP` check for the below methods in `NetworkInterface.c`, right?

- `enumIPv4Interfaces`
- `enumIPv6Interfaces`
- `getMacAddress`

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

Marked as reviewed by vyazici (Author).

PR Review: https://git.openjdk.org/jdk/pull/24653#pullrequestreview-2769434020

From duke at openjdk.org  Tue Apr 15 19:10:45 2025
From: duke at openjdk.org (Bernd)
Date: Tue, 15 Apr 2025 19:10:45 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <UR31TyJW7iC9L2h0yZfTbk-956OJ0xR6ZhMs_S3QcOg=.d3a82c69-664f-4a7a-97a3-2a58f1db0caf@github.com>

On Tue, 15 Apr 2025 12:00:10 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Is there a Risk that This breaks Applications which parses Potential UNC path as URL (or even worse want to open them?. I am not sure if this actually ever worked, but) I know people are regul?res confused about file:/// (when is it needed), and even Chat gpt suggests:

> UNC path ? \\\\server\share\file.txt
> File URL ? file://server/share/file.txt

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2807213300

From eirbjo at openjdk.org  Tue Apr 15 20:12:44 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 15 Apr 2025 20:12:44 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <UR31TyJW7iC9L2h0yZfTbk-956OJ0xR6ZhMs_S3QcOg=.d3a82c69-664f-4a7a-97a3-2a58f1db0caf@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <UR31TyJW7iC9L2h0yZfTbk-956OJ0xR6ZhMs_S3QcOg=.d3a82c69-664f-4a7a-97a3-2a58f1db0caf@github.com>
Message-ID: <2wL8iIIs6XsqkqWN-2lMJ4DMDJY_jLjHyXUbFaOBCr8=.1062245a-0cfc-4274-beb7-73990572e948@github.com>

On Tue, 15 Apr 2025 19:08:00 GMT, Bernd <duke at openjdk.org> wrote:

> Is there a Risk that This breaks Applications which parses Potential UNC path as URL (or even worse want to open them?. I am not sure if this actually ever worked, but) I know people are regul?res confused about file:/// (when is it needed), 

Thanks for raising this important concern!

The current behavior for _existing_ UNC paths would be unaffected by this change. The testing for UNC paths (by converting the path to UNC form and using `File::exists`) happens before the FTP fallback. See the Windows implementation of `Handler:openConnection`.

I've added a short mention of this in the propsed release note.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2807371582

From eirbjo at openjdk.org  Tue Apr 15 20:37:40 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 15 Apr 2025 20:37:40 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <2wL8iIIs6XsqkqWN-2lMJ4DMDJY_jLjHyXUbFaOBCr8=.1062245a-0cfc-4274-beb7-73990572e948@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <UR31TyJW7iC9L2h0yZfTbk-956OJ0xR6ZhMs_S3QcOg=.d3a82c69-664f-4a7a-97a3-2a58f1db0caf@github.com>
 <2wL8iIIs6XsqkqWN-2lMJ4DMDJY_jLjHyXUbFaOBCr8=.1062245a-0cfc-4274-beb7-73990572e948@github.com>
Message-ID: <yO3RKNNPzX8EXcpurC7RhRpzOpkDJxY4VoAWv5-MzxQ=.ab663324-8f4a-4b9a-9e3e-ca7ea2366735@github.com>

On Tue, 15 Apr 2025 20:09:39 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> The current behavior for _existing_ UNC paths would be unaffected by this change.

For the sake of completeness: 

If `Files::exists` failed for a UNC path before this change, then the code would continue to the FTP fallback and the result would depend on whether a public anonymous FTP server was available on the non-local host. 

After this change, when a UNC path does not exist, then the connection will fail with a `MalformedURLException`, just like the Unix implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2807431756

From abarashev at openjdk.org  Tue Apr 15 20:43:23 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 15 Apr 2025 20:43:23 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v6]
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <no2OS6MtYa9LIN_t_7TMdBrBv68pGIjKUCIXt-Tvng8=.e6d27a9b-c5bc-4c22-91a1-3b75cb2947c8@github.com>

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
> 
> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  To improve performance we only update when necessary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24425/files
  - new: https://git.openjdk.org/jdk/pull/24425/files/86874f33..e04bda10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=04-05

  Stats: 23 lines in 3 files changed: 11 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From abarashev at openjdk.org  Tue Apr 15 21:59:56 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 15 Apr 2025 21:59:56 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v7]
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <Udg-kns3R3Qms2r3KANRmIKv16oZaIcCf852Y70ERVQ=.3c2b38c8-2163-4b7b-8839-684b2d4280d4@github.com>

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
> 
> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Refactor existing LocalSupportedAlgs code.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24425/files
  - new: https://git.openjdk.org/jdk/pull/24425/files/e04bda10..de86b443

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=05-06

  Stats: 158 lines in 7 files changed: 32 ins; 114 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From abarashev at openjdk.org  Tue Apr 15 22:05:12 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 15 Apr 2025 22:05:12 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v8]
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <0zSavgHYD9d9ytF16hLEMz8U7B3iA8jtLJbKiU5wK_4=.120c80a9-cdf4-46ec-b5f3-c3b8ff35e668@github.com>

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
> 
> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant brackets

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24425/files
  - new: https://git.openjdk.org/jdk/pull/24425/files/de86b443..8e56207a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From abarashev at openjdk.org  Wed Apr 16 04:23:22 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 16 Apr 2025 04:23:22 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v9]
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <XtVXUDnjehH1l-L58Gx0DnMtVLUNAxRv3VYQ66BFoMw=.f8cd5275-44cd-47e7-bd1c-1e20042a5b92@github.com>

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
> 
> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24425/files
  - new: https://git.openjdk.org/jdk/pull/24425/files/8e56207a..dd089425

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=07-08

  Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From abarashev at openjdk.org  Wed Apr 16 04:28:19 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 16 Apr 2025 04:28:19 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v10]
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <j5skIFZmb77I2rl4hdQt9g7yqx5OQB7hWQOgz9XI1Z0=.ed66a3da-7985-46e3-9a13-ada0ffcc6179@github.com>

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
> 
> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.

Artur Barashev has updated the pull request incrementally with two additional commits since the last revision:

 - Remove one more newline
 - Remove extra newline

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24425/files
  - new: https://git.openjdk.org/jdk/pull/24425/files/dd089425..ce9404de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From jpai at openjdk.org  Wed Apr 16 08:15:42 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 08:15:42 GMT
Subject: RFR: 8354576: InetAddress.getLocalHost() on macos may return
 address of an interface which is not UP - leading to "Network is down" error
In-Reply-To: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
References: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
Message-ID: <jXFOn6gHrAYkeypWsZtVRbrTHKRrypvE6_yvi8jglKI=.56ad4768-df8e-4d6b-b7d0-e7da796fe45b@github.com>

On Tue, 15 Apr 2025 08:58:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8354576?
> 
> As noted in that issue, the current code in the `lookupAllHostAddr()` function of `Inet4AddressImpl.c` and `Inet6AddressImpl.c` has a macos specific implementation, where we call `getifaddrs()` and iterate over the returned addresses. In its current form this code doesn't check to see if the interface is UP or not. This can result in returing an address belonging to an interface which is not UP. That can cause subsequent usage of the address for networking operations to result in a "Network is down" error.
> 
> The commit in this PR skips interfaces that are not UP. The change only impacts the result of `getLocalHost()` call and that too only on macos. Given the nature of this change no new regression test has been introduced. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

Hello Volkan,

> We don't need this IFF_UP check for the below methods in NetworkInterface.c, right?
>    enumIPv4Interfaces
>    enumIPv6Interfaces
>    getMacAddress

These functions on `NetworkInterface.c` provide support for various APIs in the `java.net.NetworkInterface` class. The `enumIPv4Interfaces` and `enumIPv6Interfaces` are there primarily to list all available network interfaces and return the corresponding `NetworkInterface` instances. So unlike the `InetAddress.getLocalHost()` implementation, these APIs and the underlying functions merely pass along the available interfaces to the application. The `NetworkInterface` class has a `isUp()` API which the application can then use to do additional checks on that `NetworkInterface` instance.

The `getMacAddress()` function, which supports the `NetworkInterface.getHardwareAddress()` API, too doesn't need to bother about whether the interface is UP or not. So that one too doesn't require this change.

The reason `InetAddress.getLocalHost()` requires this special treatment is because that API is meant to return back an `InetAddress` of local host. It just so happens that on macos we have some special logic which iterates over interfaces to find the "right" address. Application code has no control over these network interfaces and this iteration thus needs to do these additional checks to make sure that it doesn't return back an `InetAddress` which is unusable.

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

PR Comment: https://git.openjdk.org/jdk/pull/24653#issuecomment-2808763449

From jpai at openjdk.org  Wed Apr 16 08:37:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 08:37:53 GMT
Subject: Integrated: 8354576: InetAddress.getLocalHost() on macos may return
 address of an interface which is not UP - leading to "Network is down" error
In-Reply-To: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
References: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
Message-ID: <LrUvJnw7SMDBypjd41hRhMtLateZa2TJNtr8EebfgAE=.3bf83324-a87a-4ebd-952a-6da1287ed91f@github.com>

On Tue, 15 Apr 2025 08:58:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8354576?
> 
> As noted in that issue, the current code in the `lookupAllHostAddr()` function of `Inet4AddressImpl.c` and `Inet6AddressImpl.c` has a macos specific implementation, where we call `getifaddrs()` and iterate over the returned addresses. In its current form this code doesn't check to see if the interface is UP or not. This can result in returing an address belonging to an interface which is not UP. That can cause subsequent usage of the address for networking operations to result in a "Network is down" error.
> 
> The commit in this PR skips interfaces that are not UP. The change only impacts the result of `getLocalHost()` call and that too only on macos. Given the nature of this change no new regression test has been introduced. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

This pull request has now been integrated.

Changeset: 4c3c2b32
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c3c2b32a1b9dea6f3e258cf44666932afc179e4
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8354576: InetAddress.getLocalHost() on macos may return address of an interface which is not UP - leading to "Network is down" error

Reviewed-by: alanb, dfuchs, vyazici

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

PR: https://git.openjdk.org/jdk/pull/24653

From jpai at openjdk.org  Wed Apr 16 08:37:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 08:37:53 GMT
Subject: RFR: 8354576: InetAddress.getLocalHost() on macos may return
 address of an interface which is not UP - leading to "Network is down" error
In-Reply-To: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
References: <NRrQ23bzc4Ym-L_Jd5eBGpPsdx6jl2_H-JR4VV2-eug=.0ced2aac-6ae3-46f6-a9da-6a23eccff3b7@github.com>
Message-ID: <M5v82G5PRSplm_qDgZdnowQQJb5TnbhRecBbFrMGFEM=.c08d22eb-ece8-444c-b43a-1ce03c2a754a@github.com>

On Tue, 15 Apr 2025 08:58:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8354576?
> 
> As noted in that issue, the current code in the `lookupAllHostAddr()` function of `Inet4AddressImpl.c` and `Inet6AddressImpl.c` has a macos specific implementation, where we call `getifaddrs()` and iterate over the returned addresses. In its current form this code doesn't check to see if the interface is UP or not. This can result in returing an address belonging to an interface which is not UP. That can cause subsequent usage of the address for networking operations to result in a "Network is down" error.
> 
> The commit in this PR skips interfaces that are not UP. The change only impacts the result of `getLocalHost()` call and that too only on macos. Given the nature of this change no new regression test has been introduced. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

Thank you all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/24653#issuecomment-2808819414

From duke at openjdk.org  Wed Apr 16 09:46:59 2025
From: duke at openjdk.org (Rohitash)
Date: Wed, 16 Apr 2025 09:46:59 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number [v3]
In-Reply-To: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
Message-ID: <uy4LZYJwpKjZYLVzm-4wT9nTr6zWjBXy8wcoSRoPCkA=.cd7da1a9-b8d7-44e2-acc8-efd3b0516ec8@github.com>

> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
> 
> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
> 
> 
> I ran following tests.
> 
> make test-tier1
> make test-tier2
> make test TEST=jdk/java/net

Rohitash has updated the pull request incrementally with one additional commit since the last revision:

  improve jmh benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24295/files
  - new: https://git.openjdk.org/jdk/pull/24295/files/07bff288..0164bcab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24295&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24295&range=01-02

  Stats: 12 lines in 1 file changed: 4 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24295.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24295/head:pull/24295

PR: https://git.openjdk.org/jdk/pull/24295

From michaelm at openjdk.org  Wed Apr 16 10:32:47 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 16 Apr 2025 10:32:47 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number [v3]
In-Reply-To: <uy4LZYJwpKjZYLVzm-4wT9nTr6zWjBXy8wcoSRoPCkA=.cd7da1a9-b8d7-44e2-acc8-efd3b0516ec8@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
 <uy4LZYJwpKjZYLVzm-4wT9nTr6zWjBXy8wcoSRoPCkA=.cd7da1a9-b8d7-44e2-acc8-efd3b0516ec8@github.com>
Message-ID: <3GWQ77Xk4ULtsGwTPP9_YOziNZRZXTtsg_ZkP6WymQ8=.2e3ba0fb-74fb-40fa-8eca-343ff7e6cf1a@github.com>

On Wed, 16 Apr 2025 09:46:59 GMT, Rohitash <duke at openjdk.org> wrote:

>> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
>> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
>> 
>> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
>> 
>> 
>> I ran following tests.
>> 
>> make test-tier1
>> make test-tier2
>> make test TEST=jdk/java/net
>
> Rohitash has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve jmh benchmark

This looks like a useful improvement. LGTM.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24295#pullrequestreview-2772027123

From duke at openjdk.org  Wed Apr 16 10:47:43 2025
From: duke at openjdk.org (duke)
Date: Wed, 16 Apr 2025 10:47:43 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number [v3]
In-Reply-To: <uy4LZYJwpKjZYLVzm-4wT9nTr6zWjBXy8wcoSRoPCkA=.cd7da1a9-b8d7-44e2-acc8-efd3b0516ec8@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
 <uy4LZYJwpKjZYLVzm-4wT9nTr6zWjBXy8wcoSRoPCkA=.cd7da1a9-b8d7-44e2-acc8-efd3b0516ec8@github.com>
Message-ID: <GcTh2HMbBk8G-pzs2gvVrRk5NXn83ZxoKnEwQbj7CL4=.cb77f35d-d803-4130-9c34-1a2986562b21@github.com>

On Wed, 16 Apr 2025 09:46:59 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
>> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
>> 
>> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
>> 
>> 
>> I ran following tests.
>> 
>> make test-tier1
>> make test-tier2
>> make test TEST=jdk/java/net
>
> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve jmh benchmark

@rk-kmr 
Your change (at version 0164bcab506ef529403f835ab078af06b66cdf38) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24295#issuecomment-2809185269

From aturbanov at openjdk.org  Wed Apr 16 12:07:58 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 16 Apr 2025 12:07:58 GMT
Subject: RFR: 8354826: Make ResolverConfigurationImpl.lock field final
Message-ID: <7hVv9mw8QRTeFfrQ4F9BGuHPayLgJKGgME7ApuObkVc=.120e59ba-79da-4884-9634-60bfc8d1a954@github.com>

It was made `final` in Windows version of `ResolverConfigurationImpl` under [JDK-8287104](https://bugs.openjdk.java.net/browse/JDK-8287104).

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

Commit messages:
 - [PATCH] Make ResolverConfigurationImpl.lock field final

Changes: https://git.openjdk.org/jdk/pull/14955/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14955&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354826
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14955/head:pull/14955

PR: https://git.openjdk.org/jdk/pull/14955

From alanb at openjdk.org  Wed Apr 16 12:07:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Apr 2025 12:07:58 GMT
Subject: RFR: 8354826: Make ResolverConfigurationImpl.lock field final
In-Reply-To: <7hVv9mw8QRTeFfrQ4F9BGuHPayLgJKGgME7ApuObkVc=.120e59ba-79da-4884-9634-60bfc8d1a954@github.com>
References: <7hVv9mw8QRTeFfrQ4F9BGuHPayLgJKGgME7ApuObkVc=.120e59ba-79da-4884-9634-60bfc8d1a954@github.com>
Message-ID: <MnVT3BVO74WhS6N1J0FrheQmME-QhGFVJxy7UowHvHM=.35830c04-639d-4130-8116-35bc843eefed@github.com>

On Thu, 20 Jul 2023 12:05:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It was made `final` in Windows version of `ResolverConfigurationImpl` under [JDK-8287104](https://bugs.openjdk.java.net/browse/JDK-8287104).

src/java.base/unix/classes/sun/net/dns/ResolverConfigurationImpl.java line 44:

> 42: {
> 43:     // Lock helds whilst loading configuration or checking
> 44:     private static final Object lock = new Object();

Yes, should be final. You can probably create one issue and fix all of the same issue in the same area with one JBS issue if you want.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14955#discussion_r1269464141

From michaelm at openjdk.org  Wed Apr 16 12:44:45 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 16 Apr 2025 12:44:45 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number [v3]
In-Reply-To: <uy4LZYJwpKjZYLVzm-4wT9nTr6zWjBXy8wcoSRoPCkA=.cd7da1a9-b8d7-44e2-acc8-efd3b0516ec8@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
 <uy4LZYJwpKjZYLVzm-4wT9nTr6zWjBXy8wcoSRoPCkA=.cd7da1a9-b8d7-44e2-acc8-efd3b0516ec8@github.com>
Message-ID: <aGy0S7NdY-yRNVCzOuxm5wlBLsgA4BruI7EBFGh221M=.00426948-4e20-4ed2-b284-a122bcb78919@github.com>

On Wed, 16 Apr 2025 09:46:59 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
>> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
>> 
>> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
>> 
>> 
>> I ran following tests.
>> 
>> make test-tier1
>> make test-tier2
>> make test TEST=jdk/java/net
>
> Rohitash Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve jmh benchmark

We are going to run some more tests before sponsoring this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/24295#issuecomment-2809465016

From aturbanov at openjdk.org  Wed Apr 16 13:05:44 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 16 Apr 2025 13:05:44 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number [v3]
In-Reply-To: <xopJREqd0YXFMmIn8BHXFJU7Zm10U5IEga_RstmRzdw=.92df1ed2-3f8d-4f02-8e8e-92a54696f25d@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
 <TEDiKpQktKAJ7aab7X6jIJRBEOhh3Kb1dPbJyOAfBVk=.35f73e36-c934-417d-9d52-b09890a55b6f@github.com>
 <xopJREqd0YXFMmIn8BHXFJU7Zm10U5IEga_RstmRzdw=.92df1ed2-3f8d-4f02-8e8e-92a54696f25d@github.com>
Message-ID: <-mKMEwGC0eB6saDyR5JKTqjqdxnv1qfh4JZmPSIzGRc=.2292cfd7-ae68-4191-96fe-ad20200340a9@github.com>

On Mon, 14 Apr 2025 16:34:33 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

>> test/jdk/java/net/URI/Test.java line 1791:
>> 
>>> 1789: 
>>> 1790:     // 8353013 - java.net.URI.create(String) may have low performance to scan the host/domain name from
>>> 1791:     //           URI string when the hostname starts with number
>> 
>> This comment looks a bit out of place in a unit test. I think start with a JMH benchmark and change the comment in the unit test to make it clearer that it's providing more test coverage for cases where the authority component of a hierarchical URI has a host component that starts with a number.
>
> Thanks! I have updated the comment and added a JMH benchmark.
> 
> 
> ## Before
> Benchmark                                                      (uri)  Mode  Cnt     Score    Error  Units
> URIAuthorityParsingBenchmark.create  https://98765432101.abc.xyz.com  avgt   15  1495.273 ? 86.157  ns/op
> URIAuthorityParsingBenchmark.create  https://ABCDEFGHIJK.abc.xyz.com  avgt   15   363.048 ?  6.510  ns/op
> 
> ## After
> Benchmark                                                    Mode  Cnt    Score    Error  Units
> Benchmark                                                      (uri)  Mode  Cnt    Score    Error  Units
> URIAuthorityParsingBenchmark.create  https://98765432101.abc.xyz.com  avgt   15  377.741 ? 10.497  ns/op
> URIAuthorityParsingBenchmark.create  https://ABCDEFGHIJK.abc.xyz.com  avgt   15  334.215 ?  2.148  ns/op

Isn't is suspicious that non-number case got speedup too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24295#discussion_r2046885870

From abarashev at openjdk.org  Wed Apr 16 14:57:20 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 16 Apr 2025 14:57:20 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v11]
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com>

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
> 
> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Further optimization: remove unnecessary updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24425/files
  - new: https://git.openjdk.org/jdk/pull/24425/files/ce9404de..6956caff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=09-10

  Stats: 8 lines in 3 files changed: 2 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From dfuchs at openjdk.org  Wed Apr 16 15:39:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 16 Apr 2025 15:39:53 GMT
Subject: RFR: 8354826: Make ResolverConfigurationImpl.lock field final
In-Reply-To: <7hVv9mw8QRTeFfrQ4F9BGuHPayLgJKGgME7ApuObkVc=.120e59ba-79da-4884-9634-60bfc8d1a954@github.com>
References: <7hVv9mw8QRTeFfrQ4F9BGuHPayLgJKGgME7ApuObkVc=.120e59ba-79da-4884-9634-60bfc8d1a954@github.com>
Message-ID: <3ZQVESu2K1ziCVdCJ-Al0KkZK7gebcMq9HYE6vg_zWU=.2615efb9-70ae-4a39-ad61-e47964f61daa@github.com>

On Thu, 20 Jul 2023 12:05:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It was made `final` in Windows version of `ResolverConfigurationImpl` under [JDK-8287104](https://bugs.openjdk.java.net/browse/JDK-8287104).

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14955#pullrequestreview-2772986957

From dfuchs at openjdk.org  Wed Apr 16 15:49:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 16 Apr 2025 15:49:56 GMT
Subject: RFR: 8353013: java.net.URI.create(String) may have low performance
 to scan the host/domain name from URI string when the hostname starts with
 number [v3]
In-Reply-To: <-mKMEwGC0eB6saDyR5JKTqjqdxnv1qfh4JZmPSIzGRc=.2292cfd7-ae68-4191-96fe-ad20200340a9@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
 <TEDiKpQktKAJ7aab7X6jIJRBEOhh3Kb1dPbJyOAfBVk=.35f73e36-c934-417d-9d52-b09890a55b6f@github.com>
 <xopJREqd0YXFMmIn8BHXFJU7Zm10U5IEga_RstmRzdw=.92df1ed2-3f8d-4f02-8e8e-92a54696f25d@github.com>
 <-mKMEwGC0eB6saDyR5JKTqjqdxnv1qfh4JZmPSIzGRc=.2292cfd7-ae68-4191-96fe-ad20200340a9@github.com>
Message-ID: <ZHmkzZDDy6u_3Ah8MrgdXPjhvPqjl6rJ04ecGf4gnJk=.e386bbc5-3b9b-4ea3-9520-ba2ba9e4aea6@github.com>

On Wed, 16 Apr 2025 13:03:31 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Thanks! I have updated the comment and added a JMH benchmark.
>> 
>> 
>> ## Before
>> Benchmark                                                      (uri)  Mode  Cnt     Score    Error  Units
>> URIAuthorityParsingBenchmark.create  https://98765432101.abc.xyz.com  avgt   15  1495.273 ? 86.157  ns/op
>> URIAuthorityParsingBenchmark.create  https://ABCDEFGHIJK.abc.xyz.com  avgt   15   363.048 ?  6.510  ns/op
>> 
>> ## After
>> Benchmark                                                    Mode  Cnt    Score    Error  Units
>> Benchmark                                                      (uri)  Mode  Cnt    Score    Error  Units
>> URIAuthorityParsingBenchmark.create  https://98765432101.abc.xyz.com  avgt   15  377.741 ? 10.497  ns/op
>> URIAuthorityParsingBenchmark.create  https://ABCDEFGHIJK.abc.xyz.com  avgt   15  334.215 ?  2.148  ns/op
>
> Isn't is suspicious that non-number case got speedup too?

Not sure if we should consider a 30ns speed up in a single run of the benchmark on a single node as significant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24295#discussion_r2047227114

From duke at openjdk.org  Wed Apr 16 16:11:51 2025
From: duke at openjdk.org (Rohitash Kumar)
Date: Wed, 16 Apr 2025 16:11:51 GMT
Subject: Integrated: 8353013: java.net.URI.create(String) may have low
 performance to scan the host/domain name from URI string when the hostname
 starts with number
In-Reply-To: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
References: <xset9qymmYdHeZo2OtnMBqO3V7ilt2CqdgZ_ZGaUWFI=.48a2e362-7634-4d69-889a-58e397f26376@github.com>
Message-ID: <xyHhhTBrbnmjttmOVbJV8L0mV2H8UbAoccxfw-97aJs=.0b0c47c2-fcbe-44bd-b33a-ba97aca38cf9@github.com>

On Fri, 28 Mar 2025 15:19:46 GMT, Rohitash Kumar <duke at openjdk.org> wrote:

> `scanByte` throws `NumberFormatException` for URIs that start with numbers, e.g., https://11111111.x.y/
> The current flow is `parseIPv4Address` ? `scanIPv4Address` ? `scanByte`. `parseIPv4Address` uses `NumberFormatException` for control flow, so it captures the exception, ignores it, and returns -1. This has been reported by AWS customer to cause low performance. Details: [JDK-8353013](https://bugs.openjdk.org/browse/JDK-8353013) & https://github.com/aws/aws-sdk-java-v2/issues/5933
> 
> This PR avoids NumberFormatException by skipping calls to `Integer.parseInt` if the number of digits in the octet is > 3.
> 
> 
> I ran following tests.
> 
> make test-tier1
> make test-tier2
> make test TEST=jdk/java/net

This pull request has now been integrated.

Changeset: 84458ec1
Author:    Rohitash Kumar <kurohita at amazon.com>
Committer: Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84458ec18ce33295636f7b26b8e3ff25ecb349f2
Stats:     112 lines in 3 files changed: 109 ins; 0 del; 3 mod

8353013: java.net.URI.create(String) may have low performance to scan the host/domain name from URI string when the hostname starts with number

Reviewed-by: michaelm, xpeng

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

PR: https://git.openjdk.org/jdk/pull/24295

From mullan at openjdk.org  Wed Apr 16 19:21:42 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Apr 2025 19:21:42 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v11]
In-Reply-To: <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
 <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com>
Message-ID: <ltO6VRbuYXbZUrn4T0UpKfFih9Io1851VMnbd6aGN8c=.46a3ab3b-b15c-466d-bf3e-1c8d045e698f@github.com>

On Wed, 16 Apr 2025 14:57:20 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>> 
>> 
>> Any endpoint receiving any certificate which it would need to
>> validate using any signature algorithm using an MD5 hash MUST abort
>> the handshake with a "bad_certificate" alert.
>> 
>> 
>> 
>> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
>> 
>> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
>> 
>> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further optimization: remove unnecessary updates

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24425#pullrequestreview-2773610308

From mpowers at openjdk.org  Wed Apr 16 22:05:41 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 16 Apr 2025 22:05:41 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v11]
In-Reply-To: <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
 <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com>
Message-ID: <QxPK-fUCh5m0fQCO-QvP_0i1Bz4glCtRkzowkSUvNTY=.3d412699-5367-43a0-a315-73565c2e20cb@github.com>

On Wed, 16 Apr 2025 14:57:20 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>> 
>> 
>> Any endpoint receiving any certificate which it would need to
>> validate using any signature algorithm using an MD5 hash MUST abort
>> the handshake with a "bad_certificate" alert.
>> 
>> 
>> 
>> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
>> 
>> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
>> 
>> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further optimization: remove unnecessary updates

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 1:

> 1: /*

Import of `java.security.cert.Certificate` on line 54 is unnecessary. Yea I know it's not in your code.

test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 131:

> 129: 
> 130:         // create a key store
> 131:         KeyStore ks = KeyStore.getInstance("JKS");

I wonder if PKCS12 would be a better choice in the long run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2047831632
PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2047829144

From abarashev at openjdk.org  Thu Apr 17 01:28:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 17 Apr 2025 01:28:46 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v11]
In-Reply-To: <QxPK-fUCh5m0fQCO-QvP_0i1Bz4glCtRkzowkSUvNTY=.3d412699-5367-43a0-a315-73565c2e20cb@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
 <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com>
 <QxPK-fUCh5m0fQCO-QvP_0i1Bz4glCtRkzowkSUvNTY=.3d412699-5367-43a0-a315-73565c2e20cb@github.com>
Message-ID: <-nSFuBlKNGgf34rtMgoX5sLsxz826PUGHBMruYstI9o=.dba535a6-fd57-49f8-b3b1-9daa50f851ad@github.com>

On Wed, 16 Apr 2025 22:01:04 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Further optimization: remove unnecessary updates
>
> test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 131:
> 
>> 129: 
>> 130:         // create a key store
>> 131:         KeyStore ks = KeyStore.getInstance("JKS");
> 
> I wonder if PKCS12 would be a better choice in the long run.

Updated, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2048041727

From abarashev at openjdk.org  Thu Apr 17 01:36:30 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 17 Apr 2025 01:36:30 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v12]
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <ir-kX8fBeD5CIAhq4P4p5elldMonKoFf-heMp2ljTxs=.367c100b-5f99-4d58-8087-08d1c6ea1ae2@github.com>

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
> 
> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update KeyStore type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24425/files
  - new: https://git.openjdk.org/jdk/pull/24425/files/6956caff..9146ab74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425

PR: https://git.openjdk.org/jdk/pull/24425

From mullan at openjdk.org  Thu Apr 17 12:36:49 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Apr 2025 12:36:49 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v12]
In-Reply-To: <ir-kX8fBeD5CIAhq4P4p5elldMonKoFf-heMp2ljTxs=.367c100b-5f99-4d58-8087-08d1c6ea1ae2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
 <ir-kX8fBeD5CIAhq4P4p5elldMonKoFf-heMp2ljTxs=.367c100b-5f99-4d58-8087-08d1c6ea1ae2@github.com>
Message-ID: <CmYG9dtcgXT65JVkzTCC35Syv-Jp2xOPvvJwYxPVy6U=.3d7d3619-4974-4238-8f9b-c25aa9f6bcc8@github.com>

On Thu, 17 Apr 2025 01:36:30 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>> 
>> 
>> Any endpoint receiving any certificate which it would need to
>> validate using any signature algorithm using an MD5 hash MUST abort
>> the handshake with a "bad_certificate" alert.
>> 
>> 
>> 
>> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
>> 
>> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
>> 
>> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update KeyStore type

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24425#pullrequestreview-2775576381

From abarashev at openjdk.org  Thu Apr 17 13:26:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 17 Apr 2025 13:26:08 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v11]
In-Reply-To: <QxPK-fUCh5m0fQCO-QvP_0i1Bz4glCtRkzowkSUvNTY=.3d412699-5367-43a0-a315-73565c2e20cb@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
 <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com>
 <QxPK-fUCh5m0fQCO-QvP_0i1Bz4glCtRkzowkSUvNTY=.3d412699-5367-43a0-a315-73565c2e20cb@github.com>
Message-ID: <fVrJf1P8YCCvRNQGGrUpwuA17BwIAlm6ZIkTJd5yJAA=.3d284fd3-c5f9-4a3f-b315-d68ced98fc53@github.com>

On Wed, 16 Apr 2025 22:03:07 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Further optimization: remove unnecessary updates
>
> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 1:
> 
>> 1: /*
> 
> Import of `java.security.cert.Certificate` on line 54 is unnecessary. Yea I know it's not in your code.

Those tests are going to be re-worked soon, so I guess it all will be addressed:
https://bugs.openjdk.org/browse/JDK-8353738

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2048935586

From duke at openjdk.org  Thu Apr 17 13:41:52 2025
From: duke at openjdk.org (duke)
Date: Thu, 17 Apr 2025 13:41:52 GMT
Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled
 by default are incorrectly allowed in TLSv1.3 when re-enabled [v12]
In-Reply-To: <ir-kX8fBeD5CIAhq4P4p5elldMonKoFf-heMp2ljTxs=.367c100b-5f99-4d58-8087-08d1c6ea1ae2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
 <ir-kX8fBeD5CIAhq4P4p5elldMonKoFf-heMp2ljTxs=.367c100b-5f99-4d58-8087-08d1c6ea1ae2@github.com>
Message-ID: <rqDNfhXw8GGinO953jhAKIDjH9YwdAriLYRK15kr_Uo=.0abbcc20-0421-4390-a266-d30d25ff4ce0@github.com>

On Thu, 17 Apr 2025 01:36:30 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>> 
>> 
>> Any endpoint receiving any certificate which it would need to
>> validate using any signature algorithm using an MD5 hash MUST abort
>> the handshake with a "bad_certificate" alert.
>> 
>> 
>> 
>> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
>> 
>> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
>> 
>> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update KeyStore type

@artur-oracle 
Your change (at version 9146ab740443569be06de1ba37a151d34a0c1614) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24425#issuecomment-2812967568

From abarashev at openjdk.org  Thu Apr 17 13:48:54 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 17 Apr 2025 13:48:54 GMT
Subject: Integrated: 8350807: Certificates using MD5 algorithm that are
 disabled by default are incorrectly allowed in TLSv1.3 when re-enabled
In-Reply-To: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
References: <I_h0tF20UrLIRtTkNX_3-l6twSMG-aMVNtTN3esiL2o=.513c2d5b-b592-40db-83c2-a0dd4e1f2da2@github.com>
Message-ID: <Je4z8fCfqdcVtmNFAG9XAfxqsyABFkGaTmPxhUfmSXI=.433c21bc-5109-4f7e-9bb3-452c0ec4de57@github.com>

On Thu, 3 Apr 2025 19:05:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
> 
> 
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
> 
> 
> 
> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm.
> 
> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration.
> 
> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version.

This pull request has now been integrated.

Changeset: abb23828
Author:    Artur Barashev <abarashev at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/abb23828f9dc5f4cdb75d5b924dd6f45925102cd
Stats:     482 lines in 16 files changed: 299 ins; 130 del; 53 mod

8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled

Reviewed-by: mullan

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

PR: https://git.openjdk.org/jdk/pull/24425

From dfuchs at openjdk.org  Fri Apr 18 13:29:17 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 18 Apr 2025 13:29:17 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
Message-ID: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>

Hi,

Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).

The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)

This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

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

Commit messages:
 - http3: jcheck - remove trailing white spaces
 - http3: jcheck - fixed bad file permission
 - merge latest changes from master branch
 - http3: increase keepalive timeout in H3MultipleConnectionsToSameHost.java
 - http3: improve logging on reception of stateless reset
 - http3: CSR feedback: renamed H3DiscoveryMode and associated constants
 - http3: comment update in Http3PushManager.java
 - http3: more consistent connection labels; the label now includes the underlying transport-level protocol: tcp:1, tls:2, quic:1
 - Add HTTP/3 cases to `HttpResponseConnectionLabelTest`
 - http3: adapt connection label to HttpQuicConnection after merge
 - ... and 388 more: https://git.openjdk.org/jdk/compare/4eae9b5b...9c2da664

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349910
  Stats: 102691 lines in 469 files changed: 100070 ins; 1119 del; 1502 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

PR: https://git.openjdk.org/jdk/pull/24751

From mdonovan at openjdk.org  Fri Apr 18 14:26:57 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 18 Apr 2025 14:26:57 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v3]
In-Reply-To: <AIm5JTr_STaj_hhKToFS8m3g0JI0QRJPPjtR15Q_8VM=.6de492ae-3560-41d4-a573-81d2ccebeee2@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <NfKVswsgmqoFm08V5OCTIlVEU34w1UgP5jyzAexDekA=.54ff82f5-dd56-4f86-abf6-325fab333724@github.com>
 <AIm5JTr_STaj_hhKToFS8m3g0JI0QRJPPjtR15Q_8VM=.6de492ae-3560-41d4-a573-81d2ccebeee2@github.com>
Message-ID: <bmXmxGlet3C8hrYwywfQZHLqwhoRPNYr65Kv8kvntMc=.633f8c29-f0d9-41a0-99c9-62463e51535c@github.com>

On Thu, 3 Apr 2025 20:30:33 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - reversed order of DN strings when making certificates.
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - changed boolean array initialization
>>  - 8325766: Review seclibs tests for cert expiry
>
> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 243:
> 
>> 241:                 .addBasicConstraintsExt(false, false, -1)
>> 242:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))
>> 243:                 .build(trustedCert, caKeys.getPrivate(), "MD5WithRSA");
> 
> MD5 algorithm is not allowed in TLSv1.3

I'll address this in [JDK-8353738](https://bugs.openjdk.org/browse/JDK-8353738)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2050704560

From mdonovan at openjdk.org  Fri Apr 18 14:58:41 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 18 Apr 2025 14:58:41 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
Message-ID: <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>

> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
> 
> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - expanded wildcard imports
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - reversed order of DN strings when making certificates.
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - changed boolean array initialization
 - 8325766: Review seclibs tests for cert expiry

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

Changes: https://git.openjdk.org/jdk/pull/23700/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23700&range=03
  Stats: 784 lines in 3 files changed: 158 ins; 582 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/23700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23700/head:pull/23700

PR: https://git.openjdk.org/jdk/pull/23700

From abarashev at openjdk.org  Fri Apr 18 15:42:09 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 18 Apr 2025 15:42:09 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v3]
In-Reply-To: <bmXmxGlet3C8hrYwywfQZHLqwhoRPNYr65Kv8kvntMc=.633f8c29-f0d9-41a0-99c9-62463e51535c@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <NfKVswsgmqoFm08V5OCTIlVEU34w1UgP5jyzAexDekA=.54ff82f5-dd56-4f86-abf6-325fab333724@github.com>
 <AIm5JTr_STaj_hhKToFS8m3g0JI0QRJPPjtR15Q_8VM=.6de492ae-3560-41d4-a573-81d2ccebeee2@github.com>
 <bmXmxGlet3C8hrYwywfQZHLqwhoRPNYr65Kv8kvntMc=.633f8c29-f0d9-41a0-99c9-62463e51535c@github.com>
Message-ID: <UxEZ9oWMk55kY0NZjA4BYF_k7bYDcXKvGLy23-PZxxk=.d1c84545-624f-4da9-ae73-23f54b7ce124@github.com>

On Fri, 18 Apr 2025 14:24:10 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 243:
>> 
>>> 241:                 .addBasicConstraintsExt(false, false, -1)
>>> 242:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))
>>> 243:                 .build(trustedCert, caKeys.getPrivate(), "MD5WithRSA");
>> 
>> MD5 algorithm is not allowed in TLSv1.3
>
> I'll address this in [JDK-8353738](https://bugs.openjdk.org/browse/JDK-8353738)

Sounds good, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2050786190

From abarashev at openjdk.org  Fri Apr 18 15:42:13 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 18 Apr 2025 15:42:13 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
Message-ID: <_f044UeqrNVDHSyXMWBZXOb7hu4ze8OOdBEWR457d-Y=.7d6654bc-b4e3-4bc3-9930-9b9bf13f03a5@github.com>

On Fri, 18 Apr 2025 14:58:41 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
>> 
>> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
>> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
>> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - expanded wildcard imports
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - reversed order of DN strings when making certificates.
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - changed boolean array initialization
>  - 8325766: Review seclibs tests for cert expiry

test/lib/jdk/test/lib/security/CertificateBuilder.java line 139:

> 137:      */
> 138:     public static SubjectAlternativeNameExtension createDNSSubjectAltNameExt(
> 139:             boolean critical, String dnsName) throws IOException {

Any particular reason for having this method? We already have `addSubjectAltNameDNSExt` method below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2050785449

From mdonovan at openjdk.org  Fri Apr 18 15:55:58 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 18 Apr 2025 15:55:58 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <_f044UeqrNVDHSyXMWBZXOb7hu4ze8OOdBEWR457d-Y=.7d6654bc-b4e3-4bc3-9930-9b9bf13f03a5@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <_f044UeqrNVDHSyXMWBZXOb7hu4ze8OOdBEWR457d-Y=.7d6654bc-b4e3-4bc3-9930-9b9bf13f03a5@github.com>
Message-ID: <LyX0nbMyThe2CaYileMtXkyl9kg-H3mcK5LaYLRNsoo=.97e63660-4783-4fd9-be53-501eb407e189@github.com>

On Fri, 18 Apr 2025 15:38:02 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - expanded wildcard imports
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - reversed order of DN strings when making certificates.
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - changed boolean array initialization
>>  - 8325766: Review seclibs tests for cert expiry
>
> test/lib/jdk/test/lib/security/CertificateBuilder.java line 139:
> 
>> 137:      */
>> 138:     public static SubjectAlternativeNameExtension createDNSSubjectAltNameExt(
>> 139:             boolean critical, String dnsName) throws IOException {
> 
> Any particular reason for having this method? We already have `addSubjectAltNameDNSExt` method below.

It's been a while since I wrote that method but it's probably because the existing method hardcodes the critical flag to `false`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2050800817

From abarashev at openjdk.org  Fri Apr 18 16:27:50 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 18 Apr 2025 16:27:50 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
Message-ID: <v2dHYpguYlUSPvx_7fLfE7F1csXwgPxMbBoBxa5Zz-s=.ad89f661-47b6-496f-969f-9db2764452e8@github.com>

On Fri, 18 Apr 2025 14:58:41 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
>> 
>> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
>> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
>> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - expanded wildcard imports
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - reversed order of DN strings when making certificates.
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - changed boolean array initialization
>  - 8325766: Review seclibs tests for cert expiry

LGTM

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

Marked as reviewed by abarashev (Author).

PR Review: https://git.openjdk.org/jdk/pull/23700#pullrequestreview-2778947024

From abarashev at openjdk.org  Fri Apr 18 17:31:54 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 18 Apr 2025 17:31:54 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX
Message-ID: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>

The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check of the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.

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

Commit messages:
 - Rework unit tests
 - Use standard PKIX alias
 - Merge branch 'master' into JDK-8272875
 - 8272875: Change the default key manager to PKIX

Changes: https://git.openjdk.org/jdk/pull/24756/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24756&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8272875
  Stats: 213 lines in 10 files changed: 158 ins; 25 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/24756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24756/head:pull/24756

PR: https://git.openjdk.org/jdk/pull/24756

From liach at openjdk.org  Fri Apr 18 19:03:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 19:03:51 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

src/java.net.http/share/classes/java/net/http/HttpRequest.java line 357:

> 355:          * @since TBD
> 356:          */
> 357:         public default <T> Builder setOption(HttpRequestOption<T> option, T value) { return this; }

Bikeshed: we usually omit the set prefix for builders.

src/java.net.http/share/classes/java/net/http/HttpResponse.java line 838:

> 836:         /**
> 837:          * Represents a HTTP/3 PushID. PushIds can be shared across
> 838:          * multiple client initiated requests on the same HTTP/3 connection.

Is this a marker interface for various kinds of push ids? Otherwise just the record is sufficient.

src/java.net.http/share/classes/java/net/http/HttpResponse.java line 937:

> 935:                 HttpRequest initiatingRequest,
> 936:                 HttpRequest pushPromiseRequest,
> 937:                 PushId pushid,

(Warning: I know little about HTTP, my assumptions and thus whole argument may be invalid below!)

This feels like users need to use push ids as units of synchronization on this handler, such as tracking this with a ConcurrentHashMap.

Is it possible for users to instead provide a `Function<PushId, PushPromiseHandler>` in `HttpClient::sendAsync`? I think this might make it easier for users as they no longer need to think about concurrency for different ids.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2050992217
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2050991104
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2051001758

From syan at openjdk.org  Sun Apr 20 04:08:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 20 Apr 2025 04:08:40 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics
In-Reply-To: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
Message-ID: <_Pp4u5Qcfj60EQ-h2kAw5lSxEcdwIzMNCtC2CRf4DxI=.45faaf3e-d996-4196-bcf8-58a22715c3a2@github.com>

On Thu, 10 Apr 2025 10:38:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
> 
> ### Testing
> 
> Changes can be tested as follows:
> 
> 
> make build-microbenchmark
> build/linux-x64/jdk/bin/java \
>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>   -f 1 -wi 1 -i 1 -t 2 \
>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
> 
> 
> ### Background
> 
> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
> 
> - `bind()` can fail, if the file is already created by another thread
> - the clean-up of the socket file can fail, if the file is already deleted
>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
> 
> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
> - using a dedicated (temporary and unique) parent folder for the socket
> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`

`2020, ` seems do not needed?

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

Changes requested by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24568#pullrequestreview-2780140811

From eirbjo at openjdk.org  Mon Apr 21 05:05:55 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 21 Apr 2025 05:05:55 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <GQONRI5rUAVup-sLWZlUwO3moTrmrxVa0-YKzglqRgQ=.95bd9630-55af-4d9e-83a4-2ea58582ed91@github.com>

On Tue, 15 Apr 2025 12:00:10 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 55:

> 53:             System.getProperty("sun.net.www.protocol.file.ftp-enabled", "false")
> 54:     );
> 55: 

The code for defining and checking this system property would ideally belong in `Handler.java`.

I decided to put it in `FileURLConnection.java` instead, just to avoid increasing the already significant duplication of code between unix/windows implementations of `Handler.java`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2051958681

From alanb at openjdk.org  Mon Apr 21 07:07:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Apr 2025 07:07:45 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <WD84EUcsxVzUYHlojbW1hb2bFxWKJxGre-RKmWkt4Ds=.598f4cc7-c623-4385-a1ad-66115caf9364@github.com>

On Tue, 15 Apr 2025 12:00:10 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

No objection to disabling this legacy feature by default but I think it will require writing a release note, and thus will document the system property. Right now, the proposal seems to be name the system property "sun.net.www.protocol.file.ftp-enabled" and I think we'll have to rename this to something starting with "jdk.net", and some combination of works that makes it clear that it allows file URL to make ftp connections. I can suggest some property names if you wish.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2817800677

From eirbjo at openjdk.org  Mon Apr 21 07:17:45 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 21 Apr 2025 07:17:45 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <WD84EUcsxVzUYHlojbW1hb2bFxWKJxGre-RKmWkt4Ds=.598f4cc7-c623-4385-a1ad-66115caf9364@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <WD84EUcsxVzUYHlojbW1hb2bFxWKJxGre-RKmWkt4Ds=.598f4cc7-c623-4385-a1ad-66115caf9364@github.com>
Message-ID: <WFXo6162uxVrjF-zp6kiINWbeMfPABgjhqyluiYjwKY=.d786fcad-b94b-4831-a996-a090641d2a56@github.com>

On Mon, 21 Apr 2025 07:05:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> No objection to disabling this legacy feature by default but I think it will require writing a release note, and thus will document the system property

Indeed.  A provisional release note can be found here: https://bugs.openjdk.org/browse/JDK-8354658

> Right now, the proposal seems to be name the system property "sun.net.www.protocol.file.ftp-enabled" and I think we'll have to rename this to something starting with "jdk.net", and some combination of works that makes it clear that it allows file URL to make ftp connections.

Yes, in fact I did not put much thought into the name, since I anticipated reviewers to have input on this choice anyhow. 

> I can suggest some property names if you wish.

That would be great! I'm not sure what would be a good pattern/precedence to follow here. Anything you can propose would most likely be an improvement over the current "working title" :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2817816865

From michaelm at openjdk.org  Tue Apr 22 08:56:40 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 22 Apr 2025 08:56:40 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>

On Tue, 15 Apr 2025 12:00:10 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

No objection here to this change either. I too was wondering about how this might affect UNC behavior. But, I see that processing occurs before reaching this code. 

The property will need to be documented in src/java.base/share/classes/java/net/doc-files/net-properties.html
 also.

As for the name: how about something like "jdk.net.file.ftpfallback" ?

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2820632125

From vyazici at openjdk.org  Tue Apr 22 09:44:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 22 Apr 2025 09:44:04 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v2]
In-Reply-To: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
Message-ID: <Dj2UGJ3VPbDA5BCWZe4-uRd-zII8N6kqwr2Kp-LalEo=.a229bc26-6576-41ea-a6ba-31bcde9092cf@github.com>

> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
> 
> ### Testing
> 
> Changes can be tested as follows:
> 
> 
> make build-microbenchmark
> build/linux-x64/jdk/bin/java \
>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>   -f 1 -wi 1 -i 1 -t 2 \
>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
> 
> 
> ### Background
> 
> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
> 
> - `bind()` can fail, if the file is already created by another thread
> - the clean-up of the socket file can fail, if the file is already deleted
>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
> 
> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
> - using a dedicated (temporary and unique) parent folder for the socket
> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24568/files
  - new: https://git.openjdk.org/jdk/pull/24568/files/19be0e7a..57e7ed7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24568&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24568&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24568/head:pull/24568

PR: https://git.openjdk.org/jdk/pull/24568

From vyazici at openjdk.org  Tue Apr 22 09:44:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 22 Apr 2025 09:44:04 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v2]
In-Reply-To: <_Pp4u5Qcfj60EQ-h2kAw5lSxEcdwIzMNCtC2CRf4DxI=.45faaf3e-d996-4196-bcf8-58a22715c3a2@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <_Pp4u5Qcfj60EQ-h2kAw5lSxEcdwIzMNCtC2CRf4DxI=.45faaf3e-d996-4196-bcf8-58a22715c3a2@github.com>
Message-ID: <o5r2ChlEw55U-BqkrLx4-8T6aWx6jUDNKeuT8EVN3R0=.7bbdf432-b2d4-49d0-b034-c90584e41102@github.com>

On Sun, 20 Apr 2025 04:06:33 GMT, SendaoYan <syan at openjdk.org> wrote:

> `2020, ` seems do not needed?

@sendaoYan, thanks. Removed in 57e7ed7d2b86c5fafc0da6534d989dd1388c1308.

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

PR Comment: https://git.openjdk.org/jdk/pull/24568#issuecomment-2820764869

From vyazici at openjdk.org  Tue Apr 22 09:44:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 22 Apr 2025 09:44:04 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v2]
In-Reply-To: <x3c85Jz2e2Vi-K-1Ty0_g9c4AB20I7AVmkZXuWK8XaE=.a404ea13-b4fc-47e1-ab75-bdbf152a6760@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <Dj2UGJ3VPbDA5BCWZe4-uRd-zII8N6kqwr2Kp-LalEo=.a229bc26-6576-41ea-a6ba-31bcde9092cf@github.com>
 <x3c85Jz2e2Vi-K-1Ty0_g9c4AB20I7AVmkZXuWK8XaE=.a404ea13-b4fc-47e1-ab75-bdbf152a6760@github.com>
Message-ID: <-qgQRLHGBFN6sQ37EOVXKITuiw-AUkKQAAZ4Cz0tP9k=.ac91daa1-b01d-4ba8-9cd2-24ff1d364e65@github.com>

On Tue, 22 Apr 2025 09:40:09 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright year
>
> test/micro/org/openjdk/bench/java/net/ServerUdsChannelHolder.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Fix copyright year

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24568#discussion_r2053751954

From vyazici at openjdk.org  Tue Apr 22 09:44:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 22 Apr 2025 09:44:04 GMT
Subject: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress
 provider with thread-safe close semantics [v2]
In-Reply-To: <Dj2UGJ3VPbDA5BCWZe4-uRd-zII8N6kqwr2Kp-LalEo=.a229bc26-6576-41ea-a6ba-31bcde9092cf@github.com>
References: <U02--pvckPSapwYnn3l3dJ7CsYld2qy5fP-ossyMH3o=.68194a56-5bc8-4308-94dd-e9fb8b268dbf@github.com>
 <Dj2UGJ3VPbDA5BCWZe4-uRd-zII8N6kqwr2Kp-LalEo=.a229bc26-6576-41ea-a6ba-31bcde9092cf@github.com>
Message-ID: <x3c85Jz2e2Vi-K-1Ty0_g9c4AB20I7AVmkZXuWK8XaE=.a404ea13-b4fc-47e1-ab75-bdbf152a6760@github.com>

On Tue, 22 Apr 2025 09:41:08 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
>> 
>> ### Testing
>> 
>> Changes can be tested as follows:
>> 
>> 
>> make build-microbenchmark
>> build/linux-x64/jdk/bin/java \
>>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>>   -f 1 -wi 1 -i 1 -t 2 \
>>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
>> 
>> 
>> ### Background
>> 
>> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
>> 
>> - `bind()` can fail, if the file is already created by another thread
>> - the clean-up of the socket file can fail, if the file is already deleted
>>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
>> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
>> 
>> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
>> - using a dedicated (temporary and unique) parent folder for the socket
>> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

test/micro/org/openjdk/bench/java/net/ServerUdsChannelHolder.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2025, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24568#discussion_r2053751342

From alan.bateman at oracle.com  Tue Apr 22 12:59:14 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 22 Apr 2025 13:59:14 +0100
Subject: The virtual thread is not parked in InetAddress isReachable
In-Reply-To: <CANDNq-Jsz3UEH020KG=Pz=22Fp8ioeW2pu1uOYuTXNq9-g7KQQ@mail.gmail.com>
References: <CANDNq-Jsz3UEH020KG=Pz=22Fp8ioeW2pu1uOYuTXNq9-g7KQQ@mail.gmail.com>
Message-ID: <f7ba5ab0-f920-4c27-921a-f2c5903b5880@oracle.com>

On 22/04/2025 13:18, Anton Rameykov wrote:
> :
> ? ? ? ? ? ? ? ? ? ? InetAddress address = 
> InetAddress.getByName("8.8.8.8");
> ? ? ? ? ? ? ? ? ? ? boolean reachable = address.isReachable(100);
cc'ing net-dev as that is where the networking code is maintained. Right 
now, the the IGMP and TCP implementations of isReachable are written in 
native code. These are good candidates to re-implement in Java and FFM. 
In particular, the TCP implementation (use when not root or permission 
to create raw sockets) could be migrated and should just park gracefully 
when waiting to see if a connection can be established.

-Alan

From abarashev at openjdk.org  Tue Apr 22 16:13:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 16:13:49 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 366:

> 364:     }
> 365: 
> 366:     public String chooseServerAlias(String keyType,

This method should have default (package-private) access modifier.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 375:

> 373:     }
> 374: 
> 375:     public String chooseClientAlias(String[] keyTypes, Principal[] issuers,

Same as above, the method shouldn't be public.

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

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

From abarashev at openjdk.org  Tue Apr 22 16:17:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 16:17:48 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <jvZfcaNkmERbDbJ7mXSp3TxkEPv7AjSm2AJIgAhZahw=.b0567300-9711-41e2-a079-854cd47dfbc6@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 226:

> 224:                     chc.peerSupportedAuthorities == null ? null :
> 225:                             chc.peerSupportedAuthorities.clone(),
> 226:                     chc.algorithmConstraints);

These `algorithmConstraints` won't include `peerSupportedSignAlgs`.

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

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

From abarashev at openjdk.org  Tue Apr 22 16:23:45 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 16:23:45 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <I8PsbJp206UJRkv1vA-GuQVq8rimRLZr1eeSZr6JDqE=.2165bb62-ae07-4f1f-8fbf-748e54450765@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 221:

> 219:                             chc.peerSupportedAuthorities.clone(),
> 220:                     engine);
> 221:             // TODO should we have a method that can take QuicTLSEngine?

Yes, I think we should have a method for `QuicTLSEngine` in `X509KeyManagerImpl`. In that new method we should use session's `peerSupportedSignAlgs` to construct algorithm constraints the same way we do it for `SSLSocketImpl` and for `SSLEngineImpl`. This is per TLSv1.3 RFC:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

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

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

From abarashev at openjdk.org  Tue Apr 22 16:41:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 16:41:46 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <ooatWh5P-uq9NOvehhwv-TT_GF3wF9awAZYmzuIXwCc=.4d62ff7e-ad19-44cf-a7e7-92e081fda2c4@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 265:

> 263: //                    engine, localSupportedSignAlgs, false);
> 264: //        } else {
> 265: //            constraints = SSLAlgorithmConstraints.forEngine(engine, false);

We need these to check peer's certificate against constraints specified in `java.security` config file. It looks like `SSLAlgorithmConstraints` class would need a new `forQuicTLSEngine` method.

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

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

From eirbjo at openjdk.org  Tue Apr 22 16:42:59 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 22 Apr 2025 16:42:59 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v2]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <3Pappa7rPAnG6OZvnEj1GwIOHExgXJOsANP207If61I=.1e11ab63-8685-4f5a-9fe8-a581be3132ce@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Rename system property to "jdk.net.file.ftpfallback"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/42d67659..8be0010f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=00-01

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From abarashev at openjdk.org  Tue Apr 22 16:51:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 16:51:51 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <BIio-Z0QtUmG0jk3kL8gxJjsOIxydScAlPb5DYbLUtQ=.4b83e750-328e-46c9-8434-aca1ea98a646@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 286:

> 284:         X509Certificate[] trustedChain = v.validate(chain, null,
> 285:                 Collections.emptyList(),
> 286:                 sslParameters.getAlgorithmConstraints(), authType);

SSLParameter's algorithm constraints don't include constraints specified in `java.security` config file.

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

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

From dfuchs at openjdk.org  Tue Apr 22 18:23:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Apr 2025 18:23:00 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
Message-ID: <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com>

On Fri, 18 Apr 2025 18:49:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 357:
> 
>> 355:          * @since TBD
>> 356:          */
>> 357:         public default <T> Builder setOption(HttpRequestOption<T> option, T value) { return this; }
> 
> Bikeshed: we usually omit the set prefix for builders.

I actually hesitated quite a bit on this one. We have a precedent with `Builder.setHeader(name, value)` - where the `setHeader` method replaces any value associated with the name with the given value, while `header(name, value)` would just add another value to the list of values associated with the name. I didn't want to give the impression that you could provide several values to the same option - and thus opted for naming that method `setOption`. I could let me be convinced to rename it if there is a strong concensus.

> src/java.net.http/share/classes/java/net/http/HttpResponse.java line 937:
> 
>> 935:                 HttpRequest initiatingRequest,
>> 936:                 HttpRequest pushPromiseRequest,
>> 937:                 PushId pushid,
> 
> (Warning: I know little about HTTP, my assumptions and thus whole argument may be invalid below!)
> 
> This feels like users need to use push ids as units of synchronization on this handler, such as tracking this with a ConcurrentHashMap.
> 
> Is it possible for users to instead provide a `Function<PushId, PushPromiseHandler>` in `HttpClient::sendAsync`? I think this might make it easier for users as they no longer need to think about concurrency for different ids.

PushId is an HTTP/3 concept. It would be strange to have a generic method (sendAsync) that you could call with any requests, but with a parameter that could only be used for HTTP/3. We don't have pushIds for HTTP/2. I don't think we would want to take this route.

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

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

From liach at openjdk.org  Tue Apr 22 18:50:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 18:50:48 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
 <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com>
Message-ID: <rQ7_y2FBpaa4YiK51OiVLCWPZzfxOqbIcfj4elFYEzc=.f95eea67-f5e7-4db8-8076-6d324bf05f9e@github.com>

On Tue, 22 Apr 2025 18:18:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 357:
>> 
>>> 355:          * @since TBD
>>> 356:          */
>>> 357:         public default <T> Builder setOption(HttpRequestOption<T> option, T value) { return this; }
>> 
>> Bikeshed: we usually omit the set prefix for builders.
>
> I actually hesitated quite a bit on this one. We have a precedent with `Builder.setHeader(name, value)` - where the `setHeader` method replaces any value associated with the name with the given value, while `header(name, value)` would just add another value to the list of values associated with the name. I didn't want to give the impression that you could provide several values to the same option - and thus opted for naming that method `setOption`. I could let me be convinced to rename it if there is a strong concensus.

Didn't notice we already use `set` prefix in this builder. All good; consistency is more important.

>> src/java.net.http/share/classes/java/net/http/HttpResponse.java line 937:
>> 
>>> 935:                 HttpRequest initiatingRequest,
>>> 936:                 HttpRequest pushPromiseRequest,
>>> 937:                 PushId pushid,
>> 
>> (Warning: I know little about HTTP, my assumptions and thus whole argument may be invalid below!)
>> 
>> This feels like users need to use push ids as units of synchronization on this handler, such as tracking this with a ConcurrentHashMap.
>> 
>> Is it possible for users to instead provide a `Function<PushId, PushPromiseHandler>` in `HttpClient::sendAsync`? I think this might make it easier for users as they no longer need to think about concurrency for different ids.
>
> PushId is an HTTP/3 concept. It would be strange to have a generic method (sendAsync) that you could call with any requests, but with a parameter that could only be used for HTTP/3. We don't have pushIds for HTTP/2. I don't think we would want to take this route.

Do users need to track the push ids in a thread-safe data structure like ConcurrentHashMap in a PushPromiseHandler?

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

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

From abarashev at openjdk.org  Tue Apr 22 18:58:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 18:58:58 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <fpmBtH1BrjK8EiwP1n0YFjPhKK4sYy8RR-sCA-XZ96Q=.1de608b6-2c50-4097-a8af-b969c3e702c4@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 86:

> 84:     public static void main(String[] args) throws Exception {
> 85:         // re-enable 3DES
> 86:         Security.setProperty("jdk.tls.disabledAlgorithms", "");

Use `SecurityUtils.removeFromDisabledAlgs` and only remove 3DES from this property.

test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 95:

> 93:         //System.setProperty("javax.net.ssl.keyStorePassword", PASSWORD);
> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);

Why we don't delete this?

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

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

From abarashev at openjdk.org  Tue Apr 22 19:02:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 19:02:46 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 96:

> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);
> 96:         SSLContext context = new SimpleSSLContext().get();

FYI: We are moving away from using keystore files to generating keystores on the fly as needed. `SimpleSSLContext` is using a keystore file.

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

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

From abarashev at openjdk.org  Tue Apr 22 19:13:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 19:13:48 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <ioaiTgt70-8WVynMFwzhqRD5fYJMLRsFBlexfw0KYoc=.0c515639-d11b-47ae-8199-c84b0a81a82a@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

We would need a unit test testing QUIC with `jdk.tls.disabledAlgorithms` and `jdk.certpath.disabledAlgorithms` algorithm constraints in `java.security` file. Those are currently being ignored as far as I can tell..

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

PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-2822240636

From abarashev at openjdk.org  Tue Apr 22 19:13:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 19:13:49 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
Message-ID: <rVqCd_DVMFQ-IvM8H3_h26LN-rcuKon-Zv8ZA-g2t3I=.a55a3fcf-f219-4127-b3df-278534230389@github.com>

On Tue, 22 Apr 2025 18:59:57 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 96:
> 
>> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
>> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);
>> 96:         SSLContext context = new SimpleSSLContext().get();
> 
> FYI: We are moving away from using keystore files to generating keystores on the fly as needed. `SimpleSSLContext` is using a keystore file.

`MD5NotAllowedInTLS13CertificateSignature` contains an example.

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

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

From dfuchs at openjdk.org  Tue Apr 22 19:23:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Apr 2025 19:23:49 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <rQ7_y2FBpaa4YiK51OiVLCWPZzfxOqbIcfj4elFYEzc=.f95eea67-f5e7-4db8-8076-6d324bf05f9e@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
 <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com>
 <rQ7_y2FBpaa4YiK51OiVLCWPZzfxOqbIcfj4elFYEzc=.f95eea67-f5e7-4db8-8076-6d324bf05f9e@github.com>
Message-ID: <3dsq7ir0jGHmoyAUr-mtFV5gxoWTj658lUVa7hJizDY=.46e944dd-4ffa-42fc-b877-c3ff4dc156c4@github.com>

On Tue, 22 Apr 2025 18:48:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> PushId is an HTTP/3 concept. It would be strange to have a generic method (sendAsync) that you could call with any requests, but with a parameter that could only be used for HTTP/3. We don't have pushIds for HTTP/2. I don't think we would want to take this route.
>
> Do users need to track the push ids in a thread-safe data structure like ConcurrentHashMap in a PushPromiseHandler?

Yes, they would need to provide a thread safe PushPromisHandler, but not in a way that would be significantly different than how they would need to do it for HTTP/2 server pushes, if they used the same handler with different concurrent requests.

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

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

From abarashev at openjdk.org  Tue Apr 22 19:38:47 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 22 Apr 2025 19:38:47 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <fopFSoDFZHwFvMU9afn5Z0GeiECsjaMNr0ng4-rtXAQ=.72243a2e-a505-4e2b-943c-9ec644d47a4b@github.com>

On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 1221:

> 1219:                         tm.checkClientTrusted(
> 1220:                                 certs.clone(),
> 1221:                                 authType);

This call doesn't check against `SSLAlgorithmConstraints` unlike 2 calls for `SSLSocket` and `SSLEngine` above.

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

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

From jpai at openjdk.org  Wed Apr 23 04:34:42 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 04:34:42 GMT
Subject: RFR: 8354826: Make ResolverConfigurationImpl.lock field final
In-Reply-To: <7hVv9mw8QRTeFfrQ4F9BGuHPayLgJKGgME7ApuObkVc=.120e59ba-79da-4884-9634-60bfc8d1a954@github.com>
References: <7hVv9mw8QRTeFfrQ4F9BGuHPayLgJKGgME7ApuObkVc=.120e59ba-79da-4884-9634-60bfc8d1a954@github.com>
Message-ID: <st4KY6m7PL5D4UqYDy8kakZQo7m8Sbza3mKmmirtcrM=.e50625a5-63f1-43fb-be4c-0f73a28332bc@github.com>

On Thu, 20 Jul 2023 12:05:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It was made `final` in Windows version of `ResolverConfigurationImpl` under [JDK-8287104](https://bugs.openjdk.java.net/browse/JDK-8287104).

The change looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14955#pullrequestreview-2785899692

From jwaters at openjdk.org  Wed Apr 23 06:18:50 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 23 Apr 2025 06:18:50 GMT
Subject: RFR: 8342868: Errors related to unused code on Windows after
 8339120 in core libs [v2]
In-Reply-To: <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
Message-ID: <3LBsjxpWNEAajok5P7-DTOKRKkUmGmyjudWTWlshZ64=.3780c643-dd12-489f-a237-cc3b32b642e0@github.com>

On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the got local

Stay open

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

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-2823181043

From aturbanov at openjdk.org  Wed Apr 23 06:26:09 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 23 Apr 2025 06:26:09 GMT
Subject: Integrated: 8354826: Make ResolverConfigurationImpl.lock field final
In-Reply-To: <7hVv9mw8QRTeFfrQ4F9BGuHPayLgJKGgME7ApuObkVc=.120e59ba-79da-4884-9634-60bfc8d1a954@github.com>
References: <7hVv9mw8QRTeFfrQ4F9BGuHPayLgJKGgME7ApuObkVc=.120e59ba-79da-4884-9634-60bfc8d1a954@github.com>
Message-ID: <ndOtxTB93BgkrwQjB6WpUc9dWB29_ZSFxg_jxaxbYRM=.53120c50-102b-419c-923d-f70ad9d2a8bc@github.com>

On Thu, 20 Jul 2023 12:05:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It was made `final` in Windows version of `ResolverConfigurationImpl` under [JDK-8287104](https://bugs.openjdk.java.net/browse/JDK-8287104).

This pull request has now been integrated.

Changeset: 27faf454
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27faf45422082009f23463984b8a6e43c15e9e71
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8354826: Make ResolverConfigurationImpl.lock field final

Reviewed-by: dfuchs, jpai

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

PR: https://git.openjdk.org/jdk/pull/14955

From alan.bateman at oracle.com  Wed Apr 23 06:37:18 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Apr 2025 07:37:18 +0100
Subject: The virtual thread is not parked in InetAddress isReachable
In-Reply-To: <CANDNq-LszYQwt8TCwLGmuv3PfCBiiohOeJFazgRUX2vgaaZxNA@mail.gmail.com>
References: <CANDNq-Jsz3UEH020KG=Pz=22Fp8ioeW2pu1uOYuTXNq9-g7KQQ@mail.gmail.com>
 <f7ba5ab0-f920-4c27-921a-f2c5903b5880@oracle.com>
 <CANDNq-LszYQwt8TCwLGmuv3PfCBiiohOeJFazgRUX2vgaaZxNA@mail.gmail.com>
Message-ID: <7b431f76-3a98-4c8c-8e01-ab44710f3b35@oracle.com>

On 22/04/2025 14:28, Anton Rameykov wrote:
> Alan, good day to you. I have a few questions. Could you please advise 
> me to forward my initial message to the net-dev mailing list? Sorry, 
> it's just my first time with the mailing model. And second question, 
> if the thread went to native code why Djdk.tracePinnedThreads=full 
> didn't work and didn't show debugging information.
>
The diagnostic option that used to be enabled with 
-Djdk.tracePinnedThreads=full was limited to cases where a virtual 
thread parked in Java while pinned. The scenario with 
InetAddress.isReachable is that it is implemented in native code so 
doesn't integrate with the diagnostics features that report pinning. The 
right thing here is to re-implement InetAddress.isReachable, it's just 
hasn't been high priority to do that.

-Alan

From jpai at openjdk.org  Wed Apr 23 07:58:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 07:58:01 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com>
Message-ID: <scKtNDimK4jqqoUQRw_z0PKJw1vie-cwQSEeECxvsH8=.4830e36e-5e35-4e9e-aca1-825ae08fc06d@github.com>

On Tue, 22 Apr 2025 16:10:19 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 366:
> 
>> 364:     }
>> 365: 
>> 366:     public String chooseServerAlias(String keyType,
> 
> This method should have default (package-private) access modifier.

Hello Artur, you are right. This is an overisght and we'll fix this as part of the next refresh of this PR.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 375:
> 
>> 373:     }
>> 374: 
>> 375:     public String chooseClientAlias(String[] keyTypes, Principal[] issuers,
> 
> Same as above, the method shouldn't be public.

Agreed. We will address this in the next refresh of the PR.

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

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

From jpai at openjdk.org  Wed Apr 23 08:02:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 08:02:02 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <fpmBtH1BrjK8EiwP1n0YFjPhKK4sYy8RR-sCA-XZ96Q=.1de608b6-2c50-4097-a8af-b969c3e702c4@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <fpmBtH1BrjK8EiwP1n0YFjPhKK4sYy8RR-sCA-XZ96Q=.1de608b6-2c50-4097-a8af-b969c3e702c4@github.com>
Message-ID: <xEPmIAlEHB7S1Yh3oFX3wThoJO3t8qQz2Q96jKYtU54=.7e3868bc-aaf6-4b00-b67c-2269eba9c3c2@github.com>

On Tue, 22 Apr 2025 18:56:19 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 95:
> 
>> 93:         //System.setProperty("javax.net.ssl.keyStorePassword", PASSWORD);
>> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
>> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);
> 
> Why we don't delete this?

This looks like a leftover. I'll remove this as part of the next refresh.

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

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

From jpai at openjdk.org  Wed Apr 23 08:05:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 08:05:53 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <rVqCd_DVMFQ-IvM8H3_h26LN-rcuKon-Zv8ZA-g2t3I=.a55a3fcf-f219-4127-b3df-278534230389@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
 <rVqCd_DVMFQ-IvM8H3_h26LN-rcuKon-Zv8ZA-g2t3I=.a55a3fcf-f219-4127-b3df-278534230389@github.com>
Message-ID: <HICWfI_yKD64mMPhIsGHFT5cPIw4Az-RociRzPvJUXQ=.d3150052-6cb2-486a-b149-5b5617c183d3@github.com>

On Tue, 22 Apr 2025 19:11:24 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 96:
>> 
>>> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
>>> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);
>>> 96:         SSLContext context = new SimpleSSLContext().get();
>> 
>> FYI: We are moving away from using keystore files to generating keystores on the fly as needed. `SimpleSSLContext` is using a keystore file.
>
> `MD5NotAllowedInTLS13CertificateSignature` contains an example.

A lot of (existing) HttpClient tests in `test/jdk/java/net/httpclient` currently use this `SimpleSSLContext` construct to read the `testkeys` keystore that's available in the JDK repo's test directory. Moving to a dynamically created keystore instead of a keystore that's committed in the JDK repo seems reasonable. I think it would be better to do that as a separate task in future, since that would involve updating these existing tests to use this new mechanism too.

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

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

From eirbjo at openjdk.org  Wed Apr 23 09:22:49 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 09:22:49 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v3]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <9R50GSBBrs4ScvNXajUwlYCQUB_Sebx1rjJ7RCC7Ovc=.162ede69-2243-4153-a434-2e1b1910015a@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Document jdk.net.file.ftpfallback as a Networking Property

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/8be0010f..515f4789

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=01-02

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From eirbjo at openjdk.org  Wed Apr 23 09:27:42 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 09:27:42 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v4]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <S2SIhH8bgPHxH9GZRgRq2A7l1r__jDoU9zz8E0Jdy6g=.9040ae98-da82-4aa4-8f09-41a80396186f@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Be explicit about explicit {@code ftp://} URIs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/515f4789..6b1acfd4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From eirbjo at openjdk.org  Wed Apr 23 09:31:43 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 09:31:43 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
Message-ID: <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>

On Tue, 22 Apr 2025 08:53:54 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> No objection here to this change either.

Thanks for your help in making progress here!


> The property will need to be documented in src/java.base/share/classes/java/net/doc-files/net-properties.html also.

I have made a first attempt of a text documenting the new property. Since I don't want the documentation of this feature to encourage wider use, I added some verbiage recommending that explicit `ftp://` URIs should be used instead.

Happy to take input on formatting, content and language. Here's a rendered view of the current state:

<img width="644" alt="image" src="https://github.com/user-attachments/assets/ed0ed26e-8fbb-4a7c-a7f2-95afa1ca270a" />
 
> As for the name: how about something like "jdk.net.file.ftpfallback" ?

I think this works so have renamed and updated the tests as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2823663291

From vyazici at openjdk.org  Wed Apr 23 10:24:13 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 23 Apr 2025 10:24:13 GMT
Subject: RFR: 8355370: Include server name in HTTP test server thread names to
 improve diagnostics
Message-ID: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>

Incorporates the test server name while deriving the HTTP/2 test server (i.e., `jdk.httpclient.test.lib.http2.Http2TestServer`) thread names to improve diagnostics.

### Making `HttpTestServer` implement `AutoCloseable`

I carried out this out-of-scope enhancement along with this PR, since this one-liner gives nice try-with-resources convenience while writing tests using HTTP test servers. Note that [this change is already implemented for the in-progress HTTP/3 work](/dfuch/jdk/blob/9c2da664d2875b7e7986831fd716d05b7a8306f4/test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java#L1119).

### Avoiding to improve HTTP/1.1 server thread names

We deliberately kept improving HTTP/1.1 server (shipped by `jwebserver` and delegated to for HTTP/1.1 server needs of `HttpClient` tests) thread names out of the scope in this story. `ServerImpl`, the default HTTP/1.1 server implementation, has only one thread by default: the dispatcher and it is named `HTTP-Dispatcher`. Since factory methods in `com.sun.net.httpserver.Http[s]Server` don't have the notion of a _name_, it will be a rather big change to introduce a `name` there. We could have opted for including host & port information in the `ServerImpl` dispatcher thread name, but that might expose sensitive information.

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

Commit messages:
 - Make `HttpTestServer` implement `AutoCloseable`
 - Remove redundant branching in `createExecutor`
 - Use `Thread.ofPlatform()` builder
 - Shorten thread name
 - Move `createExecutor` up
 - Move `createExecutor` to `Http2TestServer`
 - Improve canonical ctor usage in `Http2TestServer`
 - Revert `ServerImpl` changes
 - Improve HTTP server thread naming

Changes: https://git.openjdk.org/jdk/pull/24822/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24822&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355370
  Stats: 21 lines in 2 files changed: 6 ins; 6 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24822.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24822/head:pull/24822

PR: https://git.openjdk.org/jdk/pull/24822

From michaelm at openjdk.org  Wed Apr 23 10:51:46 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 23 Apr 2025 10:51:46 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com>
Message-ID: <qeuTSpwmaACYj-INcMmpNvsi0MEnxkAqlnsXTZXEJqQ=.fbae5876-717d-46e1-bf1a-029b22860f07@github.com>

On Fri, 18 Apr 2025 18:47:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> src/java.net.http/share/classes/java/net/http/HttpResponse.java line 838:
> 
>> 836:         /**
>> 837:          * Represents a HTTP/3 PushID. PushIds can be shared across
>> 838:          * multiple client initiated requests on the same HTTP/3 connection.
> 
> Is this a marker interface for various kinds of push ids? Otherwise just the record is sufficient.

We had to change the API going from HTTP/2 push promise to HTTP/3. So, we want to avoid having to do that again (except where necessary) in any future update to the definition of a Push ID. I think Push Promise is a fairly esoteric aspect of HTTP anyway and won't concern the majority of developers.

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

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

From dfuchs at openjdk.org  Wed Apr 23 11:04:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Apr 2025 11:04:56 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
 <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>
Message-ID: <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>

On Wed, 23 Apr 2025 09:28:41 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> I have made a first attempt of a text documenting the new property. Since I don't want the documentation of this feature to encourage wider use, I added some verbiage recommending that explicit `ftp://` URIs should be used instead.

Hi Eirik! 

Sorry for being late to the party. 
I too would welcome the removal of this old legacy feature. I may have more comments later (I haven't looked at the proposed code changes yet) - but here is a first feedback on the wording:

There are no handlers for URIs - only for URLs - so I would replace URI with URL in the property description to avoid any confusion. 

best regards,

-- daniel

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2823911111

From dfuchs at openjdk.org  Wed Apr 23 12:02:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Apr 2025 12:02:51 GMT
Subject: RFR: 8355370: Include server name in HTTP test server thread names
 to improve diagnostics
In-Reply-To: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
References: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
Message-ID: <MC0DX5tBP3sLFqEFRPEevi2m6F56wWoa734dJBcGrfo=.903fde8f-8445-4506-acfb-2fe6554043f2@github.com>

On Wed, 23 Apr 2025 10:18:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Incorporates the test server name while deriving the HTTP/2 test server (i.e., `jdk.httpclient.test.lib.http2.Http2TestServer`) thread names to improve diagnostics.
> 
> ### Making `HttpTestServer` implement `AutoCloseable`
> 
> I carried out this out-of-scope enhancement along with this PR, since this one-liner gives nice try-with-resources convenience while writing tests using HTTP test servers. Note that [this change is already implemented for the in-progress HTTP/3 work](/dfuch/jdk/blob/9c2da664d2875b7e7986831fd716d05b7a8306f4/test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java#L1119).
> 
> ### Avoiding to improve HTTP/1.1 server thread names
> 
> We deliberately kept improving HTTP/1.1 server (shipped by `jwebserver` and delegated to for HTTP/1.1 server needs of `HttpClient` tests) thread names out of the scope in this story. `ServerImpl`, the default HTTP/1.1 server implementation, has only one thread by default: the dispatcher and it is named `HTTP-Dispatcher`. Since factory methods in `com.sun.net.httpserver.Http[s]Server` don't have the notion of a _name_, it will be a rather big change to introduce a `name` there. We could have opted for including host & port information in the `ServerImpl` dispatcher thread name, but that might expose sensitive information.

LGTM mostly. BTW - you might want to update the PR desctription: this PR is not avoiding to improve HTTP/1.1 server thread names, but rather improving HTTP/2 test server names ;-)

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java line 789:

> 787:             stop();
> 788:         }
> 789: 

The Http2TestServer is itself closeable, so you should override this method in Http2TestServerImpl below to call `impl.close()`.

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

PR Review: https://git.openjdk.org/jdk/pull/24822#pullrequestreview-2786980597
PR Review Comment: https://git.openjdk.org/jdk/pull/24822#discussion_r2055857022

From eirbjo at openjdk.org  Wed Apr 23 12:29:03 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 12:29:03 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v5]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <kBehLI7dpnRgnGiQ6Bnt1iRQeTIAA18BJTYexrThEmM=.5b056218-01c4-4cbe-8d4f-3e498f77bbc7@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Move file URL properties out of the Proxy section, replace URI with URL

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/6b1acfd4..748bbe86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=03-04

  Stats: 21 lines in 1 file changed: 11 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From eirbjo at openjdk.org  Wed Apr 23 12:35:47 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 12:35:47 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
 <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>
 <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>
Message-ID: <zsDzMuXUyQYUgMaS1vRQGj-lvgeL8WskeL9eYF0SBiE=.3ed737d8-f2aa-446c-b30f-2d8d7586c430@github.com>

On Wed, 23 Apr 2025 11:01:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> There are no handlers for URIs - only for URLs - so I would replace URI with URL in the property description to avoid any confusion.

I just realized I had initially put this under the Proxies section. That does not make much sense, so I've extracted it to a separate H2 section as it does not seem to fit any existing section.

The Proxy section curiusly seems to use **URI** everywhere, but I've changed to using **URL** for this new section. It's a bit weird now that RFC 8089 uses URI, but maybe it's too hard to be consistent **and** correct in this case?

<img width="627" alt="image" src="https://github.com/user-attachments/assets/6de8da6c-8ba4-4858-9033-eef641235689" />

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2824135824

From eirbjo at openjdk.org  Wed Apr 23 12:39:47 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 12:39:47 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
 <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>
 <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>
Message-ID: <b-j3woVfx73o2NzVyhyjrSVa9gkn3YHgM_Gh9zf5QL4=.63982743-9996-4531-8858-76f7d75b59b3@github.com>

On Wed, 23 Apr 2025 11:01:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Sorry for being late to the party. I too would welcome the removal of this old legacy feature.

We have not really discussed a future removal of this feature in the context of this PR. This PR simply disables the feature by default.

If we want to remove it in the future, should we include text now to mention it may be removed in a future release? Or is that something to consider for a future release?

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2824147509

From abarashev at openjdk.org  Wed Apr 23 13:09:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 23 Apr 2025 13:09:48 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <HICWfI_yKD64mMPhIsGHFT5cPIw4Az-RociRzPvJUXQ=.d3150052-6cb2-486a-b149-5b5617c183d3@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
 <rVqCd_DVMFQ-IvM8H3_h26LN-rcuKon-Zv8ZA-g2t3I=.a55a3fcf-f219-4127-b3df-278534230389@github.com>
 <HICWfI_yKD64mMPhIsGHFT5cPIw4Az-RociRzPvJUXQ=.d3150052-6cb2-486a-b149-5b5617c183d3@github.com>
Message-ID: <xNTKNw56qEiRc6oU_NMnWtbD1V4FRpC63waNCUm9jdQ=.8b434d7c-8c96-42f9-8e37-4d06651da4a4@github.com>

On Wed, 23 Apr 2025 08:03:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> `MD5NotAllowedInTLS13CertificateSignature` contains an example.
>
> A lot of (existing) HttpClient tests in `test/jdk/java/net/httpclient` currently use this `SimpleSSLContext` construct to read the `testkeys` keystore that's available in the JDK repo's test directory. Moving to a dynamically created keystore instead of a keystore that's committed in the JDK repo seems reasonable. I think it would be better to do that as a separate task in future, since that would involve updating these existing tests to use this new mechanism too.

Sounds good, this was just FYI.

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

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

From jpai at openjdk.org  Wed Apr 23 13:29:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Apr 2025 13:29:53 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API
In-Reply-To: <fpmBtH1BrjK8EiwP1n0YFjPhKK4sYy8RR-sCA-XZ96Q=.1de608b6-2c50-4097-a8af-b969c3e702c4@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <fpmBtH1BrjK8EiwP1n0YFjPhKK4sYy8RR-sCA-XZ96Q=.1de608b6-2c50-4097-a8af-b969c3e702c4@github.com>
Message-ID: <gYbyu8PI9Im1Rs7zT254VDGt-x822_X9-ch37mlKdEg=.1f050845-e3a1-4fda-9f38-a2797145bf25@github.com>

On Tue, 22 Apr 2025 18:55:28 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 86:
> 
>> 84:     public static void main(String[] args) throws Exception {
>> 85:         // re-enable 3DES
>> 86:         Security.setProperty("jdk.tls.disabledAlgorithms", "");
> 
> Use `SecurityUtils.removeFromDisabledAlgs` and only remove 3DES from this property.

Thank you for pointing to `SecurityUtils`. I updated this test to use that test library and the test continues to work as expected. We will include this change in the next refresh of the PR.

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

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

From ethan at mccue.dev  Wed Apr 23 14:23:42 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 23 Apr 2025 10:23:42 -0400
Subject: Range header support
Message-ID: <CA+NR86i1L0B=7GbUMYQMdg6aFx0P-o5SA1T8nAJ=M8mFpxFDiw@mail.gmail.com>

I recently encountered a case where it would have been beneficial if
jwebserver supported the Range header.

Specifically, there was a learner who made a swing app and wanted to bundle
it as an exe or put it on the internet. The path we guided him through was
essentially

javac -d compiled --source-path src src/Main.java
jar --create --file project.jar --main-class Main -C src . -C compiled .

So they had a fully runnable jar. From there it was a bit of a lesson on
resources vs. files so that the jar could run self contained, then on to
launch4j because it can make the self contained exe they were looking for.

The other thing they wanted was the browser. Looking into the cheerpj - the
wasm jvm - it seemed as if we could also get that working pretty easily.
Their code was amenable to --release 11 and that's where Cheerpj support
currently stops (though they have stated plans to support the latest jdk.)

There were two issues with this. One is either a bug in cheerpj or their
app, still investigating. The other is that cheerpj requires support of the
Range header on whatever server is serving the jar + html file.

So ideally i would have liked to show them this html and had them run
jwebserver to see their jar run in a browser.

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8" />
    <title>CheerpJ test</title>
    <script src="https://cjrtnc.leaningtech.com/4.0/loader.js"></script>
</head>
<body>
<script>
    (async function () {
        await cheerpjInit({version: 11});
        cheerpjCreateDisplay(800, 600);
        await cheerpjRunJar("/app/project.jar");
    })();
</script>
</body>
</html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250423/26cd3329/attachment.htm>

From vyazici at openjdk.org  Wed Apr 23 14:50:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 23 Apr 2025 14:50:52 GMT
Subject: RFR: 8355370: Include server name in HTTP test server thread names
 to improve diagnostics
In-Reply-To: <MC0DX5tBP3sLFqEFRPEevi2m6F56wWoa734dJBcGrfo=.903fde8f-8445-4506-acfb-2fe6554043f2@github.com>
References: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
 <MC0DX5tBP3sLFqEFRPEevi2m6F56wWoa734dJBcGrfo=.903fde8f-8445-4506-acfb-2fe6554043f2@github.com>
Message-ID: <g88yUDVuvB9KklnRloZ0RsRpiqGlxUHW8pr3gi_not8=.830ca8ee-41ad-48cb-ad8f-064854a0b9ff@github.com>

On Wed, 23 Apr 2025 11:36:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Incorporates the test server name while deriving the HTTP/2 test server (i.e., `jdk.httpclient.test.lib.http2.Http2TestServer`) thread names to improve diagnostics.
>> 
>> ### Making `HttpTestServer` implement `AutoCloseable`
>> 
>> I carried out this out-of-scope enhancement along with this PR, since this one-liner gives nice try-with-resources convenience while writing tests using HTTP test servers. Note that [this change is already implemented for the in-progress HTTP/3 work](/dfuch/jdk/blob/9c2da664d2875b7e7986831fd716d05b7a8306f4/test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java#L1119).
>> 
>> ### Improving HTTP/2 test server thread names
>> 
>> The HTTP/2 server thread names are improved by modifying the server default executor to include the HTTP/2 server name in its thread names. We deliberately did nothing for the HTTP/1.1 server (provided by the `jdk.httpserver` module). `ServerImpl`, the default HTTP/1.1 server implementation, has only one thread by default: the dispatcher and it is named `HTTP-Dispatcher`. Since factory methods in `com.sun.net.httpserver.Http[s]Server` don?t have the notion of a _name_, introducing a name would require a public API change.
>> Instead the calling code that creates the server can supply an Executor which creates threads with whatever name
>> is appropriate for the application/test.
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java line 789:
> 
>> 787:             stop();
>> 788:         }
>> 789: 
> 
> The Http2TestServer is itself closeable, so you should override this method in Http2TestServerImpl below to call `impl.close()`.

1. What is wrong with `HttpTestServer::close` calling `HttpTestServer::stop`, which is already implemented as `impl.close()` by `Http2TestServerImpl`?
2. Shouldn't we better remove `implements AutoCloseable` and `close()` from `Http2TestServerImpl`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24822#discussion_r2056235392

From dfuchs at openjdk.org  Wed Apr 23 15:01:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Apr 2025 15:01:47 GMT
Subject: RFR: 8355370: Include server name in HTTP test server thread names
 to improve diagnostics
In-Reply-To: <g88yUDVuvB9KklnRloZ0RsRpiqGlxUHW8pr3gi_not8=.830ca8ee-41ad-48cb-ad8f-064854a0b9ff@github.com>
References: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
 <MC0DX5tBP3sLFqEFRPEevi2m6F56wWoa734dJBcGrfo=.903fde8f-8445-4506-acfb-2fe6554043f2@github.com>
 <g88yUDVuvB9KklnRloZ0RsRpiqGlxUHW8pr3gi_not8=.830ca8ee-41ad-48cb-ad8f-064854a0b9ff@github.com>
Message-ID: <RQaTXvG4pw4HPOgfMfk6VCg-efWgxusGKpkFjQDKsnY=.39847fe9-13ca-4ba3-8a80-3b15b76dd905@github.com>

On Wed, 23 Apr 2025 14:47:40 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java line 789:
>> 
>>> 787:             stop();
>>> 788:         }
>>> 789: 
>> 
>> The Http2TestServer is itself closeable, so you should override this method in Http2TestServerImpl below to call `impl.close()`.
>
> 1. What is wrong with `HttpTestServer::close` calling `HttpTestServer::stop`, which is already implemented as `impl.close()` by `Http2TestServerImpl`?
> 2. Shouldn't we better remove `implements AutoCloseable` and `close()` from `Http2TestServerImpl`?

1. If the impl is AutoCloseable then close() should call close().
2. I would actually prefer to make all implementations AutoCloseable, but that's not the point of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24822#discussion_r2056259386

From dfuchs at openjdk.org  Wed Apr 23 15:48:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Apr 2025 15:48:47 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <b-j3woVfx73o2NzVyhyjrSVa9gkn3YHgM_Gh9zf5QL4=.63982743-9996-4531-8858-76f7d75b59b3@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
 <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>
 <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>
 <b-j3woVfx73o2NzVyhyjrSVa9gkn3YHgM_Gh9zf5QL4=.63982743-9996-4531-8858-76f7d75b59b3@github.com>
Message-ID: <Vol12oXJ2D_O-meFIZyibosM91F_UP1K6eaPqIu6PvI=.a8ea37ed-638b-41d9-b039-6b20a24b46cc@github.com>

On Wed, 23 Apr 2025 12:37:20 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> We have not really discussed a future removal of this feature in the context of this PR. This PR simply disables the feature by default.

Yes - sorry my bad. The disabling of this feature (and hopefully its removal in some future version of the JDK)

>If we want to remove it in the future, should we include text now to mention it may be removed in a future release? Or is that something to consider for a future release?

Good question. I believe disabling is a good first step, which will hopefully tell us whether anyone is actually using it.
We can decide later if/when we actually want to remove it.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2824750049

From dfuchs at openjdk.org  Wed Apr 23 15:53:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Apr 2025 15:53:47 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <zsDzMuXUyQYUgMaS1vRQGj-lvgeL8WskeL9eYF0SBiE=.3ed737d8-f2aa-446c-b30f-2d8d7586c430@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
 <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>
 <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>
 <zsDzMuXUyQYUgMaS1vRQGj-lvgeL8WskeL9eYF0SBiE=.3ed737d8-f2aa-446c-b30f-2d8d7586c430@github.com>
Message-ID: <affj5tN4ZQdr1IQxIYykVl2vCR8kepcZ8_QvH4zsUG0=.de42d750-7e58-41ab-9c65-2927f1c0fa90@github.com>

On Wed, 23 Apr 2025 12:32:51 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> The Proxy section curiusly seems to use **URI** everywhere, but I've changed to using **URL** for this new section. It's a bit weird now that RFC 8089 uses URI, but maybe it's too hard to be consistent **and** correct in this case?

This is because `ProxySelector` thankfully uses URI (as in java.net.URI) not URL. So it's actually consistent *and* correct :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2824765584

From dfuchs at openjdk.org  Wed Apr 23 16:09:43 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Apr 2025 16:09:43 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v5]
In-Reply-To: <kBehLI7dpnRgnGiQ6Bnt1iRQeTIAA18BJTYexrThEmM=.5b056218-01c4-4cbe-8d4f-3e498f77bbc7@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <kBehLI7dpnRgnGiQ6Bnt1iRQeTIAA18BJTYexrThEmM=.5b056218-01c4-4cbe-8d4f-3e498f77bbc7@github.com>
Message-ID: <1d9UsH62o7LtENn3tSSsn06xKk29GOdPhiPeZMGtL7c=.e1c7f376-92b7-4c29-be29-e2e26f5ac89d@github.com>

On Wed, 23 Apr 2025 12:29:03 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move file URL properties out of the Proxy section, replace URI with URL

This looks quite good. I will run it through our CI to see if anything falls from the tree.

src/java.base/share/classes/java/net/doc-files/net-properties.html line 174:

> 172: <a id="FileHandler"></a>
> 173: <H2>File URL stream protocol handler properties</H2>
> 174: <P>The following properties are used to configure the handler for URLs with the {@code file://} scheme:</P>

I wonder if it should say the `{@code file:}` scheme instead. Although I understand that the case that interests us here is "file://some.host/some/path". Don't change anything right now - let's see if we have other opinions.

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

PR Review: https://git.openjdk.org/jdk/pull/24657#pullrequestreview-2787864603
PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2056384398

From eirbjo at openjdk.org  Wed Apr 23 17:06:44 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 17:06:44 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v5]
In-Reply-To: <1d9UsH62o7LtENn3tSSsn06xKk29GOdPhiPeZMGtL7c=.e1c7f376-92b7-4c29-be29-e2e26f5ac89d@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <kBehLI7dpnRgnGiQ6Bnt1iRQeTIAA18BJTYexrThEmM=.5b056218-01c4-4cbe-8d4f-3e498f77bbc7@github.com>
 <1d9UsH62o7LtENn3tSSsn06xKk29GOdPhiPeZMGtL7c=.e1c7f376-92b7-4c29-be29-e2e26f5ac89d@github.com>
Message-ID: <lTL-BxrSBDdV3NwRerXrK8uBtc3pi_Idr9BI57DyH6s=.9d73e27b-7737-460b-92d9-f0345b2fb06a@github.com>

On Wed, 23 Apr 2025 15:57:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I wonder if it should say the `{@code file:}` scheme instead. 

This seems like an improvement to me. Not really a deliberate choice to include the slashes on my part, probably more for consistency with other schemes under Proxy. Files with any host component should be a rarity.

> Don't change anything right now - let's see if we have other opinions.

Sure, we can let this simmer a bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2056525024

From eirbjo at openjdk.org  Wed Apr 23 17:09:55 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 17:09:55 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <Vol12oXJ2D_O-meFIZyibosM91F_UP1K6eaPqIu6PvI=.a8ea37ed-638b-41d9-b039-6b20a24b46cc@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
 <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>
 <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>
 <b-j3woVfx73o2NzVyhyjrSVa9gkn3YHgM_Gh9zf5QL4=.63982743-9996-4531-8858-76f7d75b59b3@github.com>
 <Vol12oXJ2D_O-meFIZyibosM91F_UP1K6eaPqIu6PvI=.a8ea37ed-638b-41d9-b039-6b20a24b46cc@github.com>
Message-ID: <ASTLFafoeSZH2yfzHmsOvf4Vbt5-lqxHebyZ6nk271U=.e62b3bbb-720c-45c4-a794-a4cf05ad95c4@github.com>

On Wed, 23 Apr 2025 15:46:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Good question. I believe disabling is a good first step, which will hopefully tell us whether anyone is actually using it.

I'm curious what the feelback channel would be here? Do vendors collect metrics for use of system properties, directly or indirectly through support channels such that usage of a property like this may be gauged somehow?

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2824974393

From dfuchs at openjdk.org  Wed Apr 23 17:16:42 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Apr 2025 17:16:42 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <ASTLFafoeSZH2yfzHmsOvf4Vbt5-lqxHebyZ6nk271U=.e62b3bbb-720c-45c4-a794-a4cf05ad95c4@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
 <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>
 <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>
 <b-j3woVfx73o2NzVyhyjrSVa9gkn3YHgM_Gh9zf5QL4=.63982743-9996-4531-8858-76f7d75b59b3@github.com>
 <Vol12oXJ2D_O-meFIZyibosM91F_UP1K6eaPqIu6PvI=.a8ea37ed-638b-41d9-b039-6b20a24b46cc@github.com>
 <ASTLFafoeSZH2yfzHmsOvf4Vbt5-lqxHebyZ6nk271U=.e62b3bbb-720c-45c4-a794-a4cf05ad95c4@github.com>
Message-ID: <rvsQ0lqT0a8gv8-eaDlK8v5eyFCjG3B0tn367A83W8s=.d9568d53-1657-48ec-9df7-75a85ecd9ccd@github.com>

On Wed, 23 Apr 2025 17:07:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> I'm curious what the feelback channel would be here? Do vendors collect metrics for use of system properties, directly or indirectly through support channels such that usage of a property like this may be gauged somehow?

Nothing of the sort. But if something stops working we usually get a bug report. It's possible that application maintainers will discover the property, use it, and that we won't hear about it of course.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2824991651

From eirbjo at openjdk.org  Wed Apr 23 17:26:47 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 17:26:47 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v5]
In-Reply-To: <kBehLI7dpnRgnGiQ6Bnt1iRQeTIAA18BJTYexrThEmM=.5b056218-01c4-4cbe-8d4f-3e498f77bbc7@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <kBehLI7dpnRgnGiQ6Bnt1iRQeTIAA18BJTYexrThEmM=.5b056218-01c4-4cbe-8d4f-3e498f77bbc7@github.com>
Message-ID: <vJWzU7dHhgm1_5XpEBcK-rnFRoQKVlBmkKebAwue7Uw=.41d8e957-d93a-4181-adda-b54661a481ac@github.com>

On Wed, 23 Apr 2025 12:29:03 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move file URL properties out of the Proxy section, replace URI with URL

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 242:

> 240:      static void requireFtpFallbackEnabled() throws MalformedURLException {
> 241:         if (!FTP_FALLBACK_ENABLED) {
> 242:             throw new MalformedURLException("Unsupported non-local file URL");

I aimed to keep this error message terse but informative, without revealing any parts of the URL spec.

A user stumbling on a rejected URL will not have a lot to work from here though..

If anyone have suggestions to improve the message, please chime in!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2056556441

From eirbjo at openjdk.org  Wed Apr 23 17:34:33 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 17:34:33 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Fix repeated "should should"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/748bbe86..a713dac9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From dfuchs at openjdk.org  Wed Apr 23 17:56:44 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Apr 2025 17:56:44 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v5]
In-Reply-To: <vJWzU7dHhgm1_5XpEBcK-rnFRoQKVlBmkKebAwue7Uw=.41d8e957-d93a-4181-adda-b54661a481ac@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <kBehLI7dpnRgnGiQ6Bnt1iRQeTIAA18BJTYexrThEmM=.5b056218-01c4-4cbe-8d4f-3e498f77bbc7@github.com>
 <vJWzU7dHhgm1_5XpEBcK-rnFRoQKVlBmkKebAwue7Uw=.41d8e957-d93a-4181-adda-b54661a481ac@github.com>
Message-ID: <K4igv7ZleEWx5yDmDbdhuUcdMy2WgqxBsC3d_i2rf0U=.ceef7ed0-7e86-4570-b924-74acce4c947d@github.com>

On Wed, 23 Apr 2025 17:24:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move file URL properties out of the Proxy section, replace URI with URL
>
> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 242:
> 
>> 240:      static void requireFtpFallbackEnabled() throws MalformedURLException {
>> 241:         if (!FTP_FALLBACK_ENABLED) {
>> 242:             throw new MalformedURLException("Unsupported non-local file URL");
> 
> I aimed to keep this error message terse but informative, without revealing any parts of the URL spec.
> 
> A user stumbling on a rejected URL will not have a lot to work from here though..
> 
> If anyone have suggestions to improve the message, please chime in!

I have some ideas, but you may need to wait until https://git.openjdk.org/jdk/pull/23929 is integrated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2056617051

From dfuchs at openjdk.org  Wed Apr 23 18:34:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Apr 2025 18:34:52 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <ASTLFafoeSZH2yfzHmsOvf4Vbt5-lqxHebyZ6nk271U=.e62b3bbb-720c-45c4-a794-a4cf05ad95c4@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
 <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>
 <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>
 <b-j3woVfx73o2NzVyhyjrSVa9gkn3YHgM_Gh9zf5QL4=.63982743-9996-4531-8858-76f7d75b59b3@github.com>
 <Vol12oXJ2D_O-meFIZyibosM91F_UP1K6eaPqIu6PvI=.a8ea37ed-638b-41d9-b039-6b20a24b46cc@github.com>
 <ASTLFafoeSZH2yfzHmsOvf4Vbt5-lqxHebyZ6nk271U=.e62b3bbb-720c-45c4-a794-a4cf05ad95c4@github.com>
Message-ID: <XVg57LiLI6usrry_zdcx47VTGUuYQ6dab_-aA-ddXww=.9b0181ed-2165-4191-9506-0fb8a0b47ee9@github.com>

On Wed, 23 Apr 2025 17:07:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>>> We have not really discussed a future removal of this feature in the context of this PR. This PR simply disables the feature by default.
>> 
>> Yes - sorry my bad. The disabling of this feature (and hopefully its removal in some future version of the JDK)
>> 
>>>If we want to remove it in the future, should we include text now to mention it may be removed in a future release? Or is that something to consider for a future release?
>> 
>> Good question. I believe disabling is a good first step, which will hopefully tell us whether anyone is actually using it.
>> We can decide later if/when we actually want to remove it.
>
>> Good question. I believe disabling is a good first step, which will hopefully tell us whether anyone is actually using it.
> 
> I'm curious what the feelback channel would be here? Do vendors collect metrics for use of system properties, directly or indirectly through support channels such that usage of a property like this may be gauged somehow?

@eirbjo something must be missing on windows. Two tests under `java/net/` are now failing on windows with the message: "Unsupported non-local file URL"

java/net/URL/OpenStream.java
java/net/URLConnection/UNCTest.java

Here is the stack trace for UNCTest.java for instance:


java.net.MalformedURLException: Unsupported non-local file URL
	at java.base/sun.net.www.protocol.file.FileURLConnection.requireFtpFallbackEnabled(FileURLConnection.java:242)
	at java.base/sun.net.www.protocol.file.Handler.openConnection(Handler.java:91)
	at java.base/sun.net.www.protocol.file.Handler.openConnection(Handler.java:61)
	at java.base/java.net.URL.openConnection(URL.java:1206)
	at UNCTest.main(UNCTest.java:38)


Are these tests just missing the new system property or is something more serious going on?

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2825160827

From dfuchs at openjdk.org  Wed Apr 23 18:41:46 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Apr 2025 18:41:46 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
Message-ID: <-7kFGgsoMBPwB7zQOYtuS-LBCVCTHxEpJ-iZPEJZWLM=.22ea8590-5a41-4971-801a-3fa427fe7fb0@github.com>

On Wed, 23 Apr 2025 17:34:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix repeated "should should"

OK - it seems the tests are just missing the system property. These two tests are skipped if the OS is not windows. 
The `java/net/URL/OpenStream.java` test however shows a potential compatibility issue: it was expecting `UnknownHostException` and gets `MalformedURLException` instead.

This should probably be mentioned in the compatibility risk section of the CSR, and in the release note too.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2825183643

From eirbjo at openjdk.org  Wed Apr 23 19:18:56 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 19:18:56 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <XVg57LiLI6usrry_zdcx47VTGUuYQ6dab_-aA-ddXww=.9b0181ed-2165-4191-9506-0fb8a0b47ee9@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
 <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>
 <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>
 <b-j3woVfx73o2NzVyhyjrSVa9gkn3YHgM_Gh9zf5QL4=.63982743-9996-4531-8858-76f7d75b59b3@github.com>
 <Vol12oXJ2D_O-meFIZyibosM91F_UP1K6eaPqIu6PvI=.a8ea37ed-638b-41d9-b039-6b20a24b46cc@github.com>
 <ASTLFafoeSZH2yfzHmsOvf4Vbt5-lqxHebyZ6nk271U=.e62b3bbb-720c-45c4-a794-a4cf05ad95c4@github.com>
 <XVg57LiLI6usrry_zdcx47VTGUuYQ6dab_-aA-ddXww=.9b0181ed-2165-4191-9506-0fb8a0b47ee9@github.com>
Message-ID: <ZBvxemfQVbzeGYGjF0yvIHjpMcup22eRIzJ3V13li1Q=.13d9c345-eb72-4f8e-9a77-cba9836bcdda@github.com>

On Wed, 23 Apr 2025 18:28:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> java/net/URLConnection/UNCTest.java

It's not completely clear to me whether this test was originally written under the assumption that a FileURLConnection for an UNC path would be returned by this test.

If so, the CI instance running the test would need access to an existing UNC path like `\\jdk\LOCAL-JAVA\jdk1.4\win\README.txt`.

My wild guess would be that any current CI system doesn't have this particular UNC share/file available, so instead an (unconnected) FtpURLConnection would be returned. If that's the case, then I don't think this test actually excercises the code path intended. That could only happen if the UNC path exists and a FileURLConnection was returned.

To summarize: This test wants to verify that any URLConnection to an UNC path is unconnected. Instead, since the UNC path does not exists,  it just tests that the FtpURLConnection is unconnected, which it always is and has been and which in any case seems unrelated to JDK-4401485 

Or am I missing something here?

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2825288800

From eirbjo at openjdk.org  Wed Apr 23 19:23:46 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 19:23:46 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
Message-ID: <8LOiXUosnklXuARZJC2uYc8Ax1q3P2zNuvCLtqJ6pYY=.57323bc1-998f-4a61-9376-df90d0787bce@github.com>

On Wed, 23 Apr 2025 17:34:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix repeated "should should"

> > java/net/URLConnection/UNCTest.java

> My wild guess would be that any current CI system doesn't have this particular UNC share/file available, so instead an (unconnected) FtpURLConnection would be returned. If that's the case, then I don't think this test actually excercises the code path intended. That could only happen if the UNC path exists and a FileURLConnection was returned.

As a side note:

If Handler::openConnection was updated to use `java.nio.file.Files::exists` instead of `java.io.File:exists`, then we could rewrite such tests that now rely on the UNC environment to instead mock the UNC path into existance using a custom default filesystem.

Not in scope for this PR though.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2825303793

From eirbjo at openjdk.org  Wed Apr 23 19:26:51 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 23 Apr 2025 19:26:51 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <-7kFGgsoMBPwB7zQOYtuS-LBCVCTHxEpJ-iZPEJZWLM=.22ea8590-5a41-4971-801a-3fa427fe7fb0@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
 <-7kFGgsoMBPwB7zQOYtuS-LBCVCTHxEpJ-iZPEJZWLM=.22ea8590-5a41-4971-801a-3fa427fe7fb0@github.com>
Message-ID: <kC-UCFlP4qLzag7jGdqhW__CRJICIX91VhulPt4SgpM=.4d1b43e2-6ba9-4ab0-b8a2-878b6e0a15f0@github.com>

On Wed, 23 Apr 2025 18:39:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The `java/net/URL/OpenStream.java` test however shows a potential compatibility issue: it was expecting `UnknownHostException` and gets `MalformedURLException` instead.
> 
> This should probably be mentioned in the compatibility risk section of the CSR, and in the release note too.

Yes, this is true. The RN/CSR currently focuses too narrowly on the happy path UNC handling, where the path exists. The not-so-happy path now changes the behavior from returning an FtpURLConnection (which may or may not succeed a connection) to unconditionally throwing a MUE.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2825311252

From ascarpino at openjdk.org  Wed Apr 23 23:30:42 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 23 Apr 2025 23:30:42 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX
In-Reply-To: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
Message-ID: <l9uTS_NpUUAFn8_3OliyDpGhIondRtTgvDeStnIB4vw=.7bb0107a-cf12-4672-a511-02bf206850d8@github.com>

On Fri, 18 Apr 2025 17:04:56 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check of the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.

Do we understand why this is so much slower?  I wouldn't have thought extra checking would cause this big of a performance hit.

test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 147:

> 145: 
> 146:         KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> 147:         kpg.initialize(2048);

I would not specify the key size and let the provider default set it. That could expose any problems between constraints and provider defaults, also it future proofs the test when key sizes are increased some day in the future.

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

PR Review: https://git.openjdk.org/jdk/pull/24756#pullrequestreview-2788272968
PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2056617930

From eirbjo at openjdk.org  Thu Apr 24 05:53:40 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 24 Apr 2025 05:53:40 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <kC-UCFlP4qLzag7jGdqhW__CRJICIX91VhulPt4SgpM=.4d1b43e2-6ba9-4ab0-b8a2-878b6e0a15f0@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
 <-7kFGgsoMBPwB7zQOYtuS-LBCVCTHxEpJ-iZPEJZWLM=.22ea8590-5a41-4971-801a-3fa427fe7fb0@github.com>
 <kC-UCFlP4qLzag7jGdqhW__CRJICIX91VhulPt4SgpM=.4d1b43e2-6ba9-4ab0-b8a2-878b6e0a15f0@github.com>
Message-ID: <z5d49UvVRvuU1jwT2--y4uKqxFdPPv3Nccxr0L-1bdo=.0411ada0-5c71-4045-a1dc-32f27f5ab77c@github.com>

On Wed, 23 Apr 2025 19:24:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> This should probably be mentioned in the compatibility risk section of the CSR, and in the release note too.

I have updated both to mention code affected by relying on behavior of a failing `FtpURLConnection`, such as catching `UnknownHostException`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2826459680

From vyazici at openjdk.org  Thu Apr 24 07:24:36 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 24 Apr 2025 07:24:36 GMT
Subject: RFR: 8355370: Include server name in HTTP test server thread names
 to improve diagnostics [v2]
In-Reply-To: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
References: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
Message-ID: <m9tOBilckjtfBU6v4-Osr_3GEnUUgw70bEoFRAdqjDQ=.95127309-8fd9-48e7-87df-c568431f0524@github.com>

> Incorporates the test server name while deriving the HTTP/2 test server (i.e., `jdk.httpclient.test.lib.http2.Http2TestServer`) thread names to improve diagnostics.
> 
> ### Making `HttpTestServer` implement `AutoCloseable`
> 
> I carried out this out-of-scope enhancement along with this PR, since this one-liner gives nice try-with-resources convenience while writing tests using HTTP test servers. Note that [this change is already implemented for the in-progress HTTP/3 work](/dfuch/jdk/blob/9c2da664d2875b7e7986831fd716d05b7a8306f4/test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java#L1119).
> 
> ### Improving HTTP/2 test server thread names
> 
> The HTTP/2 server thread names are improved by modifying the server default executor to include the HTTP/2 server name in its thread names. We deliberately did nothing for the HTTP/1.1 server (provided by the `jdk.httpserver` module). `ServerImpl`, the default HTTP/1.1 server implementation, has only one thread by default: the dispatcher and it is named `HTTP-Dispatcher`. Since factory methods in `com.sun.net.httpserver.Http[s]Server` don?t have the notion of a _name_, introducing a name would require a public API change.
> Instead the calling code that creates the server can supply an Executor which creates threads with whatever name
> is appropriate for the application/test.

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Fix code typo
 - Override `AutoCloseable::close` in `Http2TestServerImpl`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24822/files
  - new: https://git.openjdk.org/jdk/pull/24822/files/445468b0..ccc7b0f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24822&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24822&range=00-01

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24822.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24822/head:pull/24822

PR: https://git.openjdk.org/jdk/pull/24822

From vyazici at openjdk.org  Thu Apr 24 07:24:37 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 24 Apr 2025 07:24:37 GMT
Subject: RFR: 8355370: Include server name in HTTP test server thread names
 to improve diagnostics [v2]
In-Reply-To: <RQaTXvG4pw4HPOgfMfk6VCg-efWgxusGKpkFjQDKsnY=.39847fe9-13ca-4ba3-8a80-3b15b76dd905@github.com>
References: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
 <MC0DX5tBP3sLFqEFRPEevi2m6F56wWoa734dJBcGrfo=.903fde8f-8445-4506-acfb-2fe6554043f2@github.com>
 <g88yUDVuvB9KklnRloZ0RsRpiqGlxUHW8pr3gi_not8=.830ca8ee-41ad-48cb-ad8f-064854a0b9ff@github.com>
 <RQaTXvG4pw4HPOgfMfk6VCg-efWgxusGKpkFjQDKsnY=.39847fe9-13ca-4ba3-8a80-3b15b76dd905@github.com>
Message-ID: <jpnuNZ_SRVITOtYCU_Zd7t4k0I2nhTBJIh0hUBqqCWU=.1ecf091d-191c-4db5-ad2f-cb193bd3f4ed@github.com>

On Wed, 23 Apr 2025 14:58:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> 1. What is wrong with `HttpTestServer::close` calling `HttpTestServer::stop`, which is already implemented as `impl.close()` by `Http2TestServerImpl`?
>> 2. Shouldn't we better remove `implements AutoCloseable` and `close()` from `Http2TestServerImpl`?
>
> 1. If the impl is AutoCloseable then close() should call close().
> 2. I would actually prefer to make all implementations AutoCloseable, but that's not the point of this PR.

Implemented changes as requested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24822#discussion_r2057718592

From eirbjo at openjdk.org  Thu Apr 24 09:16:53 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 24 Apr 2025 09:16:53 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
Message-ID: <If0zmgVocdAYsheBj4G73EBMJZQPIZeGLW5GamxRKEg=.ed0b20fc-a763-411d-b6b4-d9aeaefac420@github.com>

On Wed, 23 Apr 2025 17:34:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix repeated "should should"

> > java/net/URLConnection/UNCTest.java

> This test wants to verify that any URLConnection to an UNC path is unconnected. Instead, since the UNC path does not exists, it just tests that the FtpURLConnection is unconnected, which it always is and has been and which in any case seems unrelated to JDK-4401485

Files https://bugs.openjdk.org/browse/JDK-8355475 to track an enhancement to make UNCTest use an existing Administrative Shares UNC path.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2826923618

From eirbjo at openjdk.org  Thu Apr 24 09:37:29 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 24 Apr 2025 09:37:29 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path
Message-ID: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>

Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.

The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it's supposed to.

This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.

I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.

A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.

This is a test only PR, `noreg-self` has been added in the JBS.

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

Commit messages:
 - UNCTest should use an existing UNC path

Changes: https://git.openjdk.org/jdk/pull/24842/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24842&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355475
  Stats: 33 lines in 1 file changed: 30 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24842.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24842/head:pull/24842

PR: https://git.openjdk.org/jdk/pull/24842

From dfuchs at openjdk.org  Thu Apr 24 10:05:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Apr 2025 10:05:52 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path
In-Reply-To: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
Message-ID: <FZzIWXm5UXri4ZIJdEuWRjmvIHmCgELaKPsgIcte1GQ=.6ed1e1f4-4b5f-42fe-a89f-d06a63c84f00@github.com>

On Thu, 24 Apr 2025 08:12:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.
> 
> The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it's supposed to.
> 
> This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.
> 
> I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.
> 
> A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.
> 
> This is a test only PR, `noreg-self` has been added in the JBS.

It would be good to get feedback from @bplb on this. Is the plan to integrate this change before https://git.openjdk.org/jdk/pull/24657 ?

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

PR Comment: https://git.openjdk.org/jdk/pull/24842#issuecomment-2827052458

From eirbjo at openjdk.org  Thu Apr 24 10:08:55 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 24 Apr 2025 10:08:55 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path
In-Reply-To: <FZzIWXm5UXri4ZIJdEuWRjmvIHmCgELaKPsgIcte1GQ=.6ed1e1f4-4b5f-42fe-a89f-d06a63c84f00@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
 <FZzIWXm5UXri4ZIJdEuWRjmvIHmCgELaKPsgIcte1GQ=.6ed1e1f4-4b5f-42fe-a89f-d06a63c84f00@github.com>
Message-ID: <k2PZEljR57iI09l0cYOc02o9ugydur-6sPbif0knB2c=.967918e3-f52a-482c-a962-1a7643d97e03@github.com>

On Thu, 24 Apr 2025 10:03:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> It would be good to get feedback from @bplb on this. Is the plan to integrate this change before https://git.openjdk.org/jdk/pull/24657 ?

A plan may be a strong word, but yes, that would probably be nice since we would otherwise need to deal with the failing test independently in some way.

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

PR Comment: https://git.openjdk.org/jdk/pull/24842#issuecomment-2827058819

From dfuchs at openjdk.org  Thu Apr 24 10:10:43 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Apr 2025 10:10:43 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
Message-ID: <RR3AXhrdmQzTzPYcdeXKda4KrtcDFoPf-Zj2HicJ9w8=.8e445690-be8e-4fa0-b0c5-2509bac00c31@github.com>

On Wed, 23 Apr 2025 17:34:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `sun.net.www.protocol.file.ftp-enabled` which when set to `true` re-enables the feature.
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix repeated "should should"

You will still need to update `java/net/URL/OpenStream.java` to make it pass with the new changes. Possibly have two `@run`, one with `-Djdk.net.file.ftpfallback=true` and one without and adapt the test expectation based on the presence (and value) of the property.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2827064811

From eirbjo at openjdk.org  Thu Apr 24 10:48:46 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 24 Apr 2025 10:48:46 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <RR3AXhrdmQzTzPYcdeXKda4KrtcDFoPf-Zj2HicJ9w8=.8e445690-be8e-4fa0-b0c5-2509bac00c31@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
 <RR3AXhrdmQzTzPYcdeXKda4KrtcDFoPf-Zj2HicJ9w8=.8e445690-be8e-4fa0-b0c5-2509bac00c31@github.com>
Message-ID: <BSyts0jhhtF9i7lo6GS_N_-4fpDsIYD3yi4cKiYkc-4=.58180fcb-6976-4694-8c99-cb2e0c26eb45@github.com>

On Thu, 24 Apr 2025 10:08:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> You will still need to update `java/net/URL/OpenStream.java` to make it pass with the new changes. Possibly have two `@run`, one with `-Djdk.net.file.ftpfallback=true` and one without and adapt the test expectation based on the presence (and value) of the property.

Hmm yes..

However, I find it somewhat dubious that 8202708 is crammed into this test which originally was written to test the non-proxy aspect in 4064962. Using that test to also verify that a non-existing `file://` UNC path leads to an FtpURLConnection which then fails with an `UnknownHostException` seems a bit convoluted and a mixing of concerns.

I think I would feel better if this aspect was instead verified in a new test added to the recently introduced `NonLocalFtpFallback`:


/**
 * Verify that opening a stream on a non-proxy URLConnection for a non-local
 * file URL which is not an existing UNC path fails with UnknownHostException
 * when the fallback FtpURLConnection attempts to connect to the non-existing
 * FTP server.
 *
 * See bug 8202708
 */
public void verifyFtpConnectionException() throws IOException {
    URL url  = new URL("file://h7qbp368oix47/not-exist.txt");
    assertThrows(UnknownHostException.class, () -> {
        InputStream in = url.openConnection(Proxy.NO_PROXY).getInputStream();
    });
}


We could then remove any FTP aspect from `OpenStream.java` by reverting 8202708 and keep any FTP fallback testing in the recently introduced tests (disable and not disabled). This seems cleaner to me and also reduces duplicated / redundant testing.

Any thoughts?

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2827164702

From abarashev at openjdk.org  Thu Apr 24 14:24:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 24 Apr 2025 14:24:49 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX
In-Reply-To: <l9uTS_NpUUAFn8_3OliyDpGhIondRtTgvDeStnIB4vw=.7bb0107a-cf12-4672-a511-02bf206850d8@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <l9uTS_NpUUAFn8_3OliyDpGhIondRtTgvDeStnIB4vw=.7bb0107a-cf12-4672-a511-02bf206850d8@github.com>
Message-ID: <o6sxOjxzrMx0S4N-9t_NudH6ZzOKQBhCObmmSBmlvy4=.4dff4b96-bcb4-44aa-891a-64003ff288f4@github.com>

On Wed, 23 Apr 2025 17:54:38 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>
> test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 147:
> 
>> 145: 
>> 146:         KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
>> 147:         kpg.initialize(2048);
> 
> I would not specify the key size and let the provider default set it. That could expose any problems between constraints and provider defaults, also it future proofs the test when key sizes are increased some day in the future.

I see! I'll update the test, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2058574827

From myankelevich at openjdk.org  Thu Apr 24 16:18:52 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 24 Apr 2025 16:18:52 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path
In-Reply-To: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
Message-ID: <Lvw77zQl13zGTrLc2cWz5Jl6bglj_Hs-aj5530R_8ro=.ca478914-eee6-4d19-8cd7-d4da05a1429a@github.com>

On Thu, 24 Apr 2025 08:12:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.
> 
> The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it intended to.
> 
> This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.
> 
> I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.
> 
> A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.
> 
> This is a test only PR, `noreg-self` has been added in the JBS.

test/jdk/java/net/URLConnection/UNCTest.java line 31:

> 29:  * @library /test/lib
> 30:  * @summary  Check that URL.openConnection() doesn't open connection to UNC
> 31:  * @run main UNCTest

Nitpick: Is this doing anything now?

test/jdk/java/net/URLConnection/UNCTest.java line 49:

> 47:         skipIfAdministrativeSharesDisabled(hostName);
> 48:         // Should always exist with Administrative Shares enabled
> 49:         URL url = new URL("file://" + hostName +"/C$/Windows");

AFAIK new URL is deprecated, do you think something like `new URI("file://" + hostName + "/C$/Windows").toURL();` might work better?

test/jdk/java/net/URLConnection/UNCTest.java line 65:

> 63:      * @param hostName the name of the local computer
> 64:      */
> 65:     private static void skipIfAdministrativeSharesDisabled(String hostName) {

Minor: Is this necessary in the separate method? Seems to me to be a bit too much to move a single if statement. Do you think changing the main method to this might be a bit easier to read? 


...
        // Get the "computer name" for this host
        String hostName = InetAddress.getLocalHost().getHostName();

        // Skip the test if Administrative Shares is disabled
        if (! new File("\\\" + hostName + "\\C$\\Windows").exists()) {
            throw new SkippedException("Administrative shares not enabled");
        }

        // Should always exist with Administrative Shares enabled
....


It is fine as it is too if you prefer it this way ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24842#discussion_r2058790725
PR Review Comment: https://git.openjdk.org/jdk/pull/24842#discussion_r2058793265
PR Review Comment: https://git.openjdk.org/jdk/pull/24842#discussion_r2058805825

From michaelm at openjdk.org  Thu Apr 24 16:43:43 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 24 Apr 2025 16:43:43 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v7]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <VjfnUd0_Z53U4yjGkkOnt6evq_UVc47kf3XiawTUrjU=.c39010a5-6294-4f86-a591-619db4a5f213@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  Review update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/da33863c..efabc485

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=05-06

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From dfuchs at openjdk.org  Thu Apr 24 16:59:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Apr 2025 16:59:45 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:

 - merge latest changes from master branch
 - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
 - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
 - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
 - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
 - http3: minor improvement to log message
 - http3: Artur's review - remove commented out code from test
 - http3: Artur's review - make methods package private
 - http3: qpack - allow 0 capacity when max capacity is 0
 - Remove flow control from stream limit comments
 - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=01
  Stats: 102765 lines in 470 files changed: 100142 ins; 1119 del; 1504 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

PR: https://git.openjdk.org/jdk/pull/24751

From eirbjo at openjdk.org  Thu Apr 24 17:42:44 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 24 Apr 2025 17:42:44 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path [v2]
In-Reply-To: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
Message-ID: <ZD2rTQBo0mXYvE1vTcUbrxnjN67RDFSoXGWLQOkgAyc=.2733acd0-4477-427e-876c-89fcadb3e947@github.com>

> Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.
> 
> The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it intended to.
> 
> This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.
> 
> I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.
> 
> A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.
> 
> This is a test only PR, `noreg-self` has been added in the JBS.

Eirik Bj?rsn?s 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 three additional commits since the last revision:

 - Cleanups suggested in review
 - Merge branch 'master' into unc-test-existing-path
 - UNCTest should use an existing UNC path

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24842/files
  - new: https://git.openjdk.org/jdk/pull/24842/files/71c31a7e..8c719220

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24842&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24842&range=00-01

  Stats: 47935 lines in 1163 files changed: 38028 ins; 7139 del; 2768 mod
  Patch: https://git.openjdk.org/jdk/pull/24842.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24842/head:pull/24842

PR: https://git.openjdk.org/jdk/pull/24842

From eirbjo at openjdk.org  Thu Apr 24 17:42:46 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 24 Apr 2025 17:42:46 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path [v2]
In-Reply-To: <Lvw77zQl13zGTrLc2cWz5Jl6bglj_Hs-aj5530R_8ro=.ca478914-eee6-4d19-8cd7-d4da05a1429a@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
 <Lvw77zQl13zGTrLc2cWz5Jl6bglj_Hs-aj5530R_8ro=.ca478914-eee6-4d19-8cd7-d4da05a1429a@github.com>
Message-ID: <fkp4TuUgREKvNHaUcJ5geu8C18oNbcm-d0jABcg57to=.1845d708-a141-4b89-a8ca-017b354d5aeb@github.com>

On Thu, 24 Apr 2025 16:12:17 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Eirik Bj?rsn?s 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 three additional commits since the last revision:
>> 
>>  - Cleanups suggested in review
>>  - Merge branch 'master' into unc-test-existing-path
>>  - UNCTest should use an existing UNC path
>
> test/jdk/java/net/URLConnection/UNCTest.java line 65:
> 
>> 63:      * @param hostName the name of the local computer
>> 64:      */
>> 65:     private static void skipIfAdministrativeSharesDisabled(String hostName) {
> 
> Minor: Is this necessary in the separate method? Seems to me to be a bit too much to move a single if statement. Do you think changing the main method to this might be a bit easier to read? 
> 
> 
> ...
>         // Get the "computer name" for this host
>         String hostName = InetAddress.getLocalHost().getHostName();
> 
>         // Skip the test if Administrative Shares is disabled
>         if (! new File("\\\" + hostName + "\\C$\\Windows").exists()) {
>             throw new SkippedException("Administrative shares not enabled");
>         }
> 
>         // Should always exist with Administrative Shares enabled
> ....
> 
> 
> It is fine as it is too if you prefer it this way ?

Thanks for your suggestions @myankelev. I think I've adopted all of them, so rather than commenting on each, can you take another look at the last state and see if I maybe missed something?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24842#discussion_r2058938472

From dfuchs at openjdk.org  Thu Apr 24 17:47:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Apr 2025 17:47:55 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path [v2]
In-Reply-To: <ZD2rTQBo0mXYvE1vTcUbrxnjN67RDFSoXGWLQOkgAyc=.2733acd0-4477-427e-876c-89fcadb3e947@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
 <ZD2rTQBo0mXYvE1vTcUbrxnjN67RDFSoXGWLQOkgAyc=.2733acd0-4477-427e-876c-89fcadb3e947@github.com>
Message-ID: <Ve8J1mIIJSNhVKCcPSwZ5KWuRGBwLLXX52vOCda-EuM=.edf80cdd-72e1-4b39-9869-664ee4a65d6d@github.com>

On Thu, 24 Apr 2025 17:42:44 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.
>> 
>> The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it intended to.
>> 
>> This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.
>> 
>> I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.
>> 
>> A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.
>> 
>> This is a test only PR, `noreg-self` has been added in the JBS.
>
> Eirik Bj?rsn?s 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 three additional commits since the last revision:
> 
>  - Cleanups suggested in review
>  - Merge branch 'master' into unc-test-existing-path
>  - UNCTest should use an existing UNC path

test/jdk/java/net/URLConnection/UNCTest.java line 57:

> 55:         // File URL for the UNC path
> 56:         URL url = new URI("file:" + path.replace('\\', '/')).toURL();
> 57: 

My gut feeling is that using `path.replace` here makes what's going on more obscure. I would keep the original string: `"file://" + hostName +"/C$/Windows"`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24842#discussion_r2058946721

From eirbjo at openjdk.org  Thu Apr 24 17:55:04 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 24 Apr 2025 17:55:04 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path [v3]
In-Reply-To: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
Message-ID: <YJWplSEhQI6b4PSzfQrEgrGTEuDBvjv2wyghekl_Wd0=.4bf58f12-1c41-4a00-a075-377cd966c317@github.com>

> Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.
> 
> The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it intended to.
> 
> This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.
> 
> I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.
> 
> A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.
> 
> This is a test only PR, `noreg-self` has been added in the JBS.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  String::replace was not helpful here

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24842/files
  - new: https://git.openjdk.org/jdk/pull/24842/files/8c719220..f9444bc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24842&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24842&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24842.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24842/head:pull/24842

PR: https://git.openjdk.org/jdk/pull/24842

From eirbjo at openjdk.org  Thu Apr 24 17:55:05 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 24 Apr 2025 17:55:05 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path [v2]
In-Reply-To: <Ve8J1mIIJSNhVKCcPSwZ5KWuRGBwLLXX52vOCda-EuM=.edf80cdd-72e1-4b39-9869-664ee4a65d6d@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
 <ZD2rTQBo0mXYvE1vTcUbrxnjN67RDFSoXGWLQOkgAyc=.2733acd0-4477-427e-876c-89fcadb3e947@github.com>
 <Ve8J1mIIJSNhVKCcPSwZ5KWuRGBwLLXX52vOCda-EuM=.edf80cdd-72e1-4b39-9869-664ee4a65d6d@github.com>
Message-ID: <0r_SqrWhIjjvQ1NXFF8ErmeTuLpq3PwDTuJgcaU_2wk=.31dd5c5d-4295-480d-9428-06b215821a84@github.com>

On Thu, 24 Apr 2025 17:44:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> My gut feeling is that using `path.replace` here makes what's going on more obscure. I would keep the original string: `"file://" + hostName +"/C$/Windows"`

Right, String::replace was not very helpful here. Reverted as per your suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24842#discussion_r2058953725

From abarashev at openjdk.org  Thu Apr 24 18:30:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 24 Apr 2025 18:30:00 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v2]
In-Reply-To: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
Message-ID: <vY4EPwbma2L152XinG4QKBSoLZAavCk0xv8xFx2jlJ8=.2a8e342f-7c76-42c8-944f-09a542f2315a@github.com>

> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
> 
> Compatibility considerations:
> 
> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
> 
> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
> 
> **SUNX509**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> Finished running test 'micro:java.security.SSLHandshake'
> 
> **PKIX**
> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
> Finished running test 'micro:java.security.SSLHandshake'

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Skip explicit KeyPair initialization and let the provider default set it

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24756/files
  - new: https://git.openjdk.org/jdk/pull/24756/files/19a2ad1d..e5e83514

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24756&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24756&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24756/head:pull/24756

PR: https://git.openjdk.org/jdk/pull/24756

From abarashev at openjdk.org  Thu Apr 24 19:05:05 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 24 Apr 2025 19:05:05 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v2]
In-Reply-To: <l9uTS_NpUUAFn8_3OliyDpGhIondRtTgvDeStnIB4vw=.7bb0107a-cf12-4672-a511-02bf206850d8@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <l9uTS_NpUUAFn8_3OliyDpGhIondRtTgvDeStnIB4vw=.7bb0107a-cf12-4672-a511-02bf206850d8@github.com>
Message-ID: <pdH9M4vp6_Hn2Pv1z6XdXGq-PWf9uEy2qLSlmlhGDo8=.3d148d2f-beb0-4362-a1b3-883f2c06b382@github.com>

On Wed, 23 Apr 2025 23:28:29 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Do we understand why this is so much slower? I wouldn't have thought extra checking would cause this big of a performance hit.

Yes, it looks that way. `SunX509` KeyManager is really simple, so adding certificate validation can decrease the performance significantly. The discussion of #17956 contains an extensive performance analyses.

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

PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2828599943

From djelinski at openjdk.org  Thu Apr 24 19:17:47 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Apr 2025 19:17:47 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v2]
In-Reply-To: <vY4EPwbma2L152XinG4QKBSoLZAavCk0xv8xFx2jlJ8=.2a8e342f-7c76-42c8-944f-09a542f2315a@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <vY4EPwbma2L152XinG4QKBSoLZAavCk0xv8xFx2jlJ8=.2a8e342f-7c76-42c8-944f-09a542f2315a@github.com>
Message-ID: <1wkSzYpzruxGnsBswCgGt-VW-MusNzCIIQ_hHF9WAmI=.f3f22c74-2dae-415c-8dba-814c78df6029@github.com>

On Thu, 24 Apr 2025 18:30:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Skip explicit KeyPair initialization and let the provider default set it

> The discussion of https://github.com/openjdk/jdk/pull/17956 contains an extensive performance analyses.

TL;DR: PKCS12 decrypts the private key before every use. The performance hit comes from applying PBKDF2 to the key encryption password.

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

PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2828625887

From jpai at openjdk.org  Fri Apr 25 02:20:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Apr 2025 02:20:54 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <scKtNDimK4jqqoUQRw_z0PKJw1vie-cwQSEeECxvsH8=.4830e36e-5e35-4e9e-aca1-825ae08fc06d@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com>
 <scKtNDimK4jqqoUQRw_z0PKJw1vie-cwQSEeECxvsH8=.4830e36e-5e35-4e9e-aca1-825ae08fc06d@github.com>
Message-ID: <O_Ia72dEGLYqoqg0jZ5OF9c7_amCP-FSZNudfe2taBA=.775c0d70-a247-405e-b317-66879753a9cd@github.com>

On Wed, 23 Apr 2025 07:54:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 366:
>> 
>>> 364:     }
>>> 365: 
>>> 366:     public String chooseServerAlias(String keyType,
>> 
>> This method should have default (package-private) access modifier.
>
> Hello Artur, you are right. This is an overisght and we'll fix this as part of the next refresh of this PR.

This is now addressed in the latest update to this PR.

>> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 375:
>> 
>>> 373:     }
>>> 374: 
>>> 375:     public String chooseClientAlias(String[] keyTypes, Principal[] issuers,
>> 
>> Same as above, the method shouldn't be public.
>
> Agreed. We will address this in the next refresh of the PR.

This is now addressed in the latest update to this PR.

>> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 86:
>> 
>>> 84:     public static void main(String[] args) throws Exception {
>>> 85:         // re-enable 3DES
>>> 86:         Security.setProperty("jdk.tls.disabledAlgorithms", "");
>> 
>> Use `SecurityUtils.removeFromDisabledAlgs` and only remove 3DES from this property.
>
> Thank you for pointing to `SecurityUtils`. I updated this test to use that test library and the test continues to work as expected. We will include this change in the next refresh of the PR.

This too is now addressed in the latest update to this PR.

>> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 95:
>> 
>>> 93:         //System.setProperty("javax.net.ssl.keyStorePassword", PASSWORD);
>>> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
>>> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);
>> 
>> Why we don't delete this?
>
> This looks like a leftover. I'll remove this as part of the next refresh.

Addressed in the latest update to this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464244
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464328
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464619
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464758

From jai.forums2013 at gmail.com  Fri Apr 25 05:58:37 2025
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 25 Apr 2025 11:28:37 +0530
Subject: Range header support
In-Reply-To: <CA+NR86i1L0B=7GbUMYQMdg6aFx0P-o5SA1T8nAJ=M8mFpxFDiw@mail.gmail.com>
References: <CA+NR86i1L0B=7GbUMYQMdg6aFx0P-o5SA1T8nAJ=M8mFpxFDiw@mail.gmail.com>
Message-ID: <bf2cf70e-873d-4d32-952d-a0f44fefedf6@gmail.com>

Hello Ethan,

This seems to be a reasonable enhancement request. I have filed 
https://bugs.openjdk.org/browse/JDK-8355572 to track this.

Given other priority tasks, this enhancement may not be worked upon 
soon. However, on first sight, this appears to be a reasonably sized 
change isolated to a very specific part of the code. So if you or anyone 
else would like to contribute to this enhancement, please send a message 
to this mailing list (the contribution guide is here 
https://openjdk.org/guide/). I think this enhancement would require a 
bit of experimenting with the code and some back and forth discussions. 
That's OK and can be done here in this mailing list.

-Jaikiran

On 23/04/25 7:53 pm, Ethan McCue wrote:
> I recently encountered a case where it would have been beneficial if 
> jwebserver?supported the Range header.
>
> Specifically, there was a learner who made a swing app and wanted to 
> bundle it as an exe or put it on the internet. The path we guided him 
> through was essentially
>
> javac -d compiled --source-path src src/Main.java
> jar --create --file project.jar --main-class Main -C src . -C compiled .
>
> So they had a fully runnable jar. From there it was a bit of a lesson 
> on resources vs. files so that the jar could run self contained, then 
> on to launch4j because it can make the self contained exe they were 
> looking for.
>
> The other thing they wanted was the browser. Looking into the 
> cheerpj?- the wasm jvm - it seemed as if we could also get that 
> working pretty easily. Their code was amenable?to --release 11?and 
> that's where Cheerpj support currently stops (though they have stated 
> plans to support the latest jdk.)
>
> There were two issues with this. One is either a bug in cheerpj?or 
> their app, still investigating. The other is that cheerpj?requires 
> support of the Range header on whatever server is serving the jar?+ 
> html file.
>
> So ideally i would have liked to show them this html and had them run 
> jwebserver?to see their jar run in a browser.
>
> <!doctype html>
> <html lang="en">
> <head>
> ? ? <meta charset="utf-8" />
> ? ? <title>CheerpJ test</title>
> ? ? <script src="https://cjrtnc.leaningtech.com/4.0/loader.js"></script>
> </head>
> <body>
> <script>
> ? ? (async function () {
> ? ? ? ? await cheerpjInit({version: 11});
> ? ? ? ? cheerpjCreateDisplay(800, 600);
> ? ? ? ? await cheerpjRunJar("/app/project.jar");
> ? ? })();
> </script>
> </body>
> </html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250425/3d2c80ec/attachment.htm>

From eirbjo at openjdk.org  Fri Apr 25 06:19:30 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 06:19:30 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path [v4]
In-Reply-To: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
Message-ID: <BTzicufTdH_tzDa2tAcolMTgFnKV7fciJL1WMUGgi2s=.1c23c6c8-8a84-4d0b-b704-1de0c4bd11f4@github.com>

> Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.
> 
> The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it intended to.
> 
> This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.
> 
> I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.
> 
> A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.
> 
> This is a test only PR, `noreg-self` has been added in the JBS.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Some spell fixes and comment tweaks
 - Use Java-style array declaration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24842/files
  - new: https://git.openjdk.org/jdk/pull/24842/files/f9444bc5..235185c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24842&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24842&range=02-03

  Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24842.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24842/head:pull/24842

PR: https://git.openjdk.org/jdk/pull/24842

From eirbjo at openjdk.org  Fri Apr 25 09:29:33 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 09:29:33 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v7]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <YhlB2TvT1inBSYdOOnUXQl6ZJKaorzG-CRyap7WA5bo=.1e6f15f6-e1d6-4b0a-876a-a2f350216b0a@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s 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 nine additional commits since the last revision:

 - Move testing of exceptional behavior of a non-local, FTP-fallback enabled file URL from OpenStream to NonLocalFtpFallback
 - Add a test verifying that local file URLs such as 'file://localhost/folder/data.xml' are not affected by the FTP fallback feature being enabled
 - Merge branch 'master' into disable-non-local-file-urls
 - Fix repeated "should should"
 - Move file URL properties out of the Proxy section, replace URI with URL
 - Be explicit about explicit {@code ftp://} URIs
 - Document jdk.net.file.ftpfallback as a Networking Property
 - Rename system property to "jdk.net.file.ftpfallback"
 - Disable non-local file URLs by default

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/a713dac9..5b11c073

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=05-06

  Stats: 47963 lines in 1164 files changed: 38059 ins; 7137 del; 2767 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From eirbjo at openjdk.org  Fri Apr 25 09:29:47 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 09:29:47 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
Message-ID: <GghDYKg6KrFk1oAQMwS0hCWRHauYUGNVZVonpB334kI=.9203c69b-ca85-4061-a96c-5ad40d2397cf@github.com>

On Wed, 23 Apr 2025 17:34:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix repeated "should should"

>> You will still need to update java/net/URL/OpenStream.java to make it pass with the new changes

> I think I would feel better if this aspect was instead verified in a new test added to the recently introduced `NonLocalFtpFallback`

@dfuch I went ahead and implemented this in 5b11c07, could you have a look?

Should be easy to revert if you are opposed to this solution for fixing the currently failing `OpenStream` test.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2829878459

From eirbjo at openjdk.org  Fri Apr 25 09:41:35 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 09:41:35 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v8]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <zmyZz8rEjAT5xbetx5AkqjH-Lpzi-g1u4cwvqxTYyOY=.c62ddd8f-4136-4dd3-9cd4-857cdc55578e@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  verifyNonLocalFileURLRejected is a better name for this test which expects the FTP fallback to be disabled

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/5b11c073..4982af02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From dfuchs at openjdk.org  Fri Apr 25 09:48:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Apr 2025 09:48:58 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <RR3AXhrdmQzTzPYcdeXKda4KrtcDFoPf-Zj2HicJ9w8=.8e445690-be8e-4fa0-b0c5-2509bac00c31@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
 <RR3AXhrdmQzTzPYcdeXKda4KrtcDFoPf-Zj2HicJ9w8=.8e445690-be8e-4fa0-b0c5-2509bac00c31@github.com>
Message-ID: <Yx6NpJvPQwIHXTMKz9dhedWRlSPFfr_q2iVCMh_zmSU=.9aad94a9-45e9-4fb1-9b71-e6e87b9b2972@github.com>

On Thu, 24 Apr 2025 10:08:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix repeated "should should"
>
> You will still need to update `java/net/URL/OpenStream.java` to make it pass with the new changes. Possibly have two `@run`, one with `-Djdk.net.file.ftpfallback=true` and one without and adapt the test expectation based on the presence (and value) of the property.

> @dfuch I went ahead and implemented this in [5b11c07](https://github.com/openjdk/jdk/commit/5b11c073190a2bc42adf2a789407bbea9e100e7c), could you have a look?
> 
> Should be easy to revert if you are opposed to this solution for fixing the currently failing `OpenStream` test.

LGTM. I wonder if we need to add a comment in OpenStream that "bad" UNC paths are tested in NonLocalFtpFallback.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2829917803

From eirbjo at openjdk.org  Fri Apr 25 10:01:05 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 10:01:05 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <Yx6NpJvPQwIHXTMKz9dhedWRlSPFfr_q2iVCMh_zmSU=.9aad94a9-45e9-4fb1-9b71-e6e87b9b2972@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
 <RR3AXhrdmQzTzPYcdeXKda4KrtcDFoPf-Zj2HicJ9w8=.8e445690-be8e-4fa0-b0c5-2509bac00c31@github.com>
 <Yx6NpJvPQwIHXTMKz9dhedWRlSPFfr_q2iVCMh_zmSU=.9aad94a9-45e9-4fb1-9b71-e6e87b9b2972@github.com>
Message-ID: <aR-j4LMAOjafu34YdwmYGNLU0FXv6tm7kHe-MY4rE6o=.99038195-e965-4f6e-8586-abed1cf79e61@github.com>

On Fri, 25 Apr 2025 09:44:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I wonder if we need to add a comment in OpenStream that "bad" UNC paths are tested in NonLocalFtpFallback.

We could. But there is technincally no such thing as a "bad" UNC path though. If File::exists fails, then it isn't considered a UNC path, so would fall back to FtpURLConnection. But so would the Unix implementation of `Handler::openConnection`, which has no concept of UNC. (Notice how the test I added to `NonLocalFtpFallback` is not specific to Windows)

So this testing is verifying network exceptions happing from FtpURLConnection. It isn't really UNC nor Windows-specific. With this in mind, the existing `OpenStream::testUnc` seems somewhat suspicious, so I'm worried a comment would be just as confusing, at least if mentioning UNC.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2829950737

From eirbjo at openjdk.org  Fri Apr 25 10:08:57 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 10:08:57 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <aR-j4LMAOjafu34YdwmYGNLU0FXv6tm7kHe-MY4rE6o=.99038195-e965-4f6e-8586-abed1cf79e61@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
 <RR3AXhrdmQzTzPYcdeXKda4KrtcDFoPf-Zj2HicJ9w8=.8e445690-be8e-4fa0-b0c5-2509bac00c31@github.com>
 <Yx6NpJvPQwIHXTMKz9dhedWRlSPFfr_q2iVCMh_zmSU=.9aad94a9-45e9-4fb1-9b71-e6e87b9b2972@github.com>
 <aR-j4LMAOjafu34YdwmYGNLU0FXv6tm7kHe-MY4rE6o=.99038195-e965-4f6e-8586-abed1cf79e61@github.com>
Message-ID: <Kl565lMQcTHQTH0PgU8YQ7bF-E8hNQWqwuZaJ5hGaIs=.c808ff4b-e338-4362-be95-6970f56c2ec2@github.com>

On Fri, 25 Apr 2025 09:55:52 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>  I wonder if we need to add a comment in OpenStream that "bad" UNC paths are tested in NonLocalFtpFallback.

Could we say something like: _For testing of non-local file URLs with the legacy FTP fallback feature enabled, see NonLocalFtpFallback._

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2829976845

From dfuchs at openjdk.org  Fri Apr 25 10:19:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Apr 2025 10:19:58 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path [v4]
In-Reply-To: <BTzicufTdH_tzDa2tAcolMTgFnKV7fciJL1WMUGgi2s=.1c23c6c8-8a84-4d0b-b704-1de0c4bd11f4@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
 <BTzicufTdH_tzDa2tAcolMTgFnKV7fciJL1WMUGgi2s=.1c23c6c8-8a84-4d0b-b704-1de0c4bd11f4@github.com>
Message-ID: <JG5LNlu6N3QT0Yl6TBejgPa4gcC-QkUswQPQzNJ5LYY=.1d981302-f2be-40d9-bf08-0aaeb172de41@github.com>

On Fri, 25 Apr 2025 06:19:30 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.
>> 
>> The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it intended to.
>> 
>> This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.
>> 
>> I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.
>> 
>> A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.
>> 
>> This is a test only PR, `noreg-self` has been added in the JBS.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Some spell fixes and comment tweaks
>  - Use Java-style array declaration

Marked as reviewed by dfuchs (Reviewer).

I ran the test in our CI, and the test is not skipped.

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

PR Review: https://git.openjdk.org/jdk/pull/24842#pullrequestreview-2793663917
PR Comment: https://git.openjdk.org/jdk/pull/24842#issuecomment-2830006950

From myankelevich at openjdk.org  Fri Apr 25 10:22:56 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 25 Apr 2025 10:22:56 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path [v4]
In-Reply-To: <BTzicufTdH_tzDa2tAcolMTgFnKV7fciJL1WMUGgi2s=.1c23c6c8-8a84-4d0b-b704-1de0c4bd11f4@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
 <BTzicufTdH_tzDa2tAcolMTgFnKV7fciJL1WMUGgi2s=.1c23c6c8-8a84-4d0b-b704-1de0c4bd11f4@github.com>
Message-ID: <UrxcSvwkKxVWK2y4G3TalzKfbuFrwX4MzSMVK0Vr54I=.7dfabb80-f54d-42b5-8ee8-c4a539501c45@github.com>

On Fri, 25 Apr 2025 06:19:30 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.
>> 
>> The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it intended to.
>> 
>> This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.
>> 
>> I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.
>> 
>> A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.
>> 
>> This is a test only PR, `noreg-self` has been added in the JBS.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Some spell fixes and comment tweaks
>  - Use Java-style array declaration

Looks good to me now, thank you for your changes

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

PR Comment: https://git.openjdk.org/jdk/pull/24842#issuecomment-2830016438

From eirbjo at openjdk.org  Fri Apr 25 11:12:55 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 11:12:55 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v9]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <xXRjuiMFdggoSMx_Eo344turTrxU5va1JMqJ6vBTHlw=.7b945f7f-d650-4531-a885-5bb114dde468@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Add @comment referencing testing of non-local file URLs in NonLocalFtpFallback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/4982af02..4ad1ab8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=07-08

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From dfuchs at openjdk.org  Fri Apr 25 11:16:08 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Apr 2025 11:16:08 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path [v4]
In-Reply-To: <BTzicufTdH_tzDa2tAcolMTgFnKV7fciJL1WMUGgi2s=.1c23c6c8-8a84-4d0b-b704-1de0c4bd11f4@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
 <BTzicufTdH_tzDa2tAcolMTgFnKV7fciJL1WMUGgi2s=.1c23c6c8-8a84-4d0b-b704-1de0c4bd11f4@github.com>
Message-ID: <iL0gF0jso3ep7Fvm7PkRvmBnqlKEK2p7Unhnxe43l-Y=.91b4d877-1109-4ff1-a9c7-c0429f752f2f@github.com>

On Fri, 25 Apr 2025 06:19:30 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.
>> 
>> The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it intended to.
>> 
>> This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.
>> 
>> I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.
>> 
>> A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.
>> 
>> This is a test only PR, `noreg-self` has been added in the JBS.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Some spell fixes and comment tweaks
>  - Use Java-style array declaration

For what I'm concerned this is good to go. Feel free to integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/24842#issuecomment-2830123974

From eirbjo at openjdk.org  Fri Apr 25 11:19:59 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 11:19:59 GMT
Subject: RFR: 8355475: UNCTest should use an existing UNC path [v4]
In-Reply-To: <iL0gF0jso3ep7Fvm7PkRvmBnqlKEK2p7Unhnxe43l-Y=.91b4d877-1109-4ff1-a9c7-c0429f752f2f@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
 <BTzicufTdH_tzDa2tAcolMTgFnKV7fciJL1WMUGgi2s=.1c23c6c8-8a84-4d0b-b704-1de0c4bd11f4@github.com>
 <iL0gF0jso3ep7Fvm7PkRvmBnqlKEK2p7Unhnxe43l-Y=.91b4d877-1109-4ff1-a9c7-c0429f752f2f@github.com>
Message-ID: <zKwK8FC4RtHLUCWjxTpJFWU5Vk4aQ4SHBfRro1G2Wmk=.0f7c531c-5814-47a0-9437-e3bbd2d4d2f6@github.com>

On Fri, 25 Apr 2025 11:13:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Some spell fixes and comment tweaks
>>  - Use Java-style array declaration
>
> For what I'm concerned this is good to go. Feel free to integrate.

Thank you @dfuch and @myankelev for helpful suggestions, reviews and CI verification!

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

PR Comment: https://git.openjdk.org/jdk/pull/24842#issuecomment-2830130265

From eirbjo at openjdk.org  Fri Apr 25 11:19:59 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 11:19:59 GMT
Subject: Integrated: 8355475: UNCTest should use an existing UNC path
In-Reply-To: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
References: <47ZQs_0TJ8w9yEHr-1EmMQB_LeHGKQZ1rP8TP_KH1kQ=.5939433d-c7a6-4336-ada7-809dda5c56d9@github.com>
Message-ID: <_K89_aAyxI1bFea8Pj1bEehe3r20W8t5LGOgy3w_YFk=.28af80e9-87b4-4f76-9d64-523decb1440c@github.com>

On Thu, 24 Apr 2025 08:12:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which updates `UNCTest.java` to use a UNC path which is known to exist.
> 
> The test currently uses the file URL `file://jdk/LOCAL-JAVA/jdk1.4/win/README.txt`, but since this is unlikely to resolve to an existing UNC path on any CI server, the test doesn't really verify what it intended to.
> 
> This PR changes the test to instead use the path `file://computername/C$/Windows`, which should always be available unless Administrative Shares has been disabled. We detect this case by using File::exists for the path and simply skip the test if it does not exist.
> 
> I forced this test to run in tier1 on GHA and verified that it ran successfully, without being skipped. Meaning Administrative Shares is enabled in the Windows GHA instance.
> 
> A test run in Oracle's CI verifying a successful run (without skipping) would be welcome.
> 
> This is a test only PR, `noreg-self` has been added in the JBS.

This pull request has now been integrated.

Changeset: e6cea402
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6cea4025b6743538da76f056fa831b02705f423
Stats:     34 lines in 1 file changed: 30 ins; 1 del; 3 mod

8355475: UNCTest should use an existing UNC path

Reviewed-by: dfuchs

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

PR: https://git.openjdk.org/jdk/pull/24842

From eirbjo at openjdk.org  Fri Apr 25 11:24:11 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 11:24:11 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v10]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <alH_36iuDRDdDG3OvzXXbzQVlOMuh0zoH2Aqt9C6Z_8=.42317dbf-31ea-4ac8-b758-4a98f43737c3@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change. I plan to update the CSR pending an initial round of review of this PR.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s 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 12 additional commits since the last revision:

 - Merge branch 'master' into disable-non-local-file-urls
 - Add @comment referencing testing of non-local file URLs in NonLocalFtpFallback
 - verifyNonLocalFileURLRejected is a better name for this test which expects the FTP fallback to be disabled
 - Move testing of exceptional behavior of a non-local, FTP-fallback enabled file URL from OpenStream to NonLocalFtpFallback
 - Add a test verifying that local file URLs such as 'file://localhost/folder/data.xml' are not affected by the FTP fallback feature being enabled
 - Merge branch 'master' into disable-non-local-file-urls
 - Fix repeated "should should"
 - Move file URL properties out of the Proxy section, replace URI with URL
 - Be explicit about explicit {@code ftp://} URIs
 - Document jdk.net.file.ftpfallback as a Networking Property
 - ... and 2 more: https://git.openjdk.org/jdk/compare/58f93f9f...af73727f

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/4ad1ab8e..af73727f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=08-09

  Stats: 3176 lines in 134 files changed: 1959 ins; 828 del; 389 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From eirbjo at openjdk.org  Fri Apr 25 11:26:51 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 11:26:51 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default
In-Reply-To: <XVg57LiLI6usrry_zdcx47VTGUuYQ6dab_-aA-ddXww=.9b0181ed-2165-4191-9506-0fb8a0b47ee9@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <vgMvm_zguOeWDUbqeuaKjRybneiPI4wxgmjnzNcq3qc=.46462e24-038b-4700-810e-e447829b4c4f@github.com>
 <i72CYUsGDG14E9Ca-F1yat1MT3BV7xZza38s6w37Tuc=.8e2c9f5b-28ef-438d-9f30-b912d80cd9d7@github.com>
 <gmM0AKJW5IoykQmJQUE3A0ndnzvIsUmILIOErY7Apyw=.493ac4e0-6036-477f-8f6c-e3d3432d2328@github.com>
 <b-j3woVfx73o2NzVyhyjrSVa9gkn3YHgM_Gh9zf5QL4=.63982743-9996-4531-8858-76f7d75b59b3@github.com>
 <Vol12oXJ2D_O-meFIZyibosM91F_UP1K6eaPqIu6PvI=.a8ea37ed-638b-41d9-b039-6b20a24b46cc@github.com>
 <ASTLFafoeSZH2yfzHmsOvf4Vbt5-lqxHebyZ6nk271U=.e62b3bbb-720c-45c4-a794-a4cf05ad95c4@github.com>
 <XVg57LiLI6usrry_zdcx47VTGUuYQ6dab_-aA-ddXww=.9b0181ed-2165-4191-9506-0fb8a0b47ee9@github.com>
Message-ID: <eR15SM0qaU3s2x5QFhav-EMKf9yGiR-8FyKDzxjV83o=.aee399b0-1d6d-4d47-a403-0328c354bffc@github.com>

On Wed, 23 Apr 2025 18:28:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Two tests under `java/net/` are now failing on windows with the message: "Unsupported non-local file URL"
> 
> java/net/URL/OpenStream.java
> java/net/URLConnection/UNCTest.java

With the updates to `OpenStream` in this PR and the updates to `UNCTest` merged in from master, these two failing tests should now have been takes care of.

@dfuch Would you consider giving these updated tests a spin on Oracle CI to verify?

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2830146386

From dfuchs at openjdk.org  Fri Apr 25 12:30:46 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Apr 2025 12:30:46 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <Yx6NpJvPQwIHXTMKz9dhedWRlSPFfr_q2iVCMh_zmSU=.9aad94a9-45e9-4fb1-9b71-e6e87b9b2972@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
 <RR3AXhrdmQzTzPYcdeXKda4KrtcDFoPf-Zj2HicJ9w8=.8e445690-be8e-4fa0-b0c5-2509bac00c31@github.com>
 <Yx6NpJvPQwIHXTMKz9dhedWRlSPFfr_q2iVCMh_zmSU=.9aad94a9-45e9-4fb1-9b71-e6e87b9b2972@github.com>
Message-ID: <3AyJ-64HfhxiD02r2iXCzQbadbuaTGXtcQqxi8R0PWY=.7023cba4-30d3-45de-a4eb-621538a9270f@github.com>

On Fri, 25 Apr 2025 09:44:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> You will still need to update `java/net/URL/OpenStream.java` to make it pass with the new changes. Possibly have two `@run`, one with `-Djdk.net.file.ftpfallback=true` and one without and adapt the test expectation based on the presence (and value) of the property.
>
>> @dfuch I went ahead and implemented this in [5b11c07](https://github.com/openjdk/jdk/commit/5b11c073190a2bc42adf2a789407bbea9e100e7c), could you have a look?
>> 
>> Should be easy to revert if you are opposed to this solution for fixing the currently failing `OpenStream` test.
> 
> LGTM. I wonder if we need to add a comment in OpenStream that "bad" UNC paths are tested in NonLocalFtpFallback.

> @dfuch Would you consider giving these updated tests a spin on Oracle CI to verify?

Will do. The CSR could also be moved to "Proposed".

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2830286825

From eirbjo at openjdk.org  Fri Apr 25 12:30:46 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 12:30:46 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v6]
In-Reply-To: <3AyJ-64HfhxiD02r2iXCzQbadbuaTGXtcQqxi8R0PWY=.7023cba4-30d3-45de-a4eb-621538a9270f@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Ozcc3oWYDyxXg1J8nvwXmVa2flUOaIaDgW7Byz6ANeM=.7352e765-b209-406d-b685-156e76bd4d02@github.com>
 <RR3AXhrdmQzTzPYcdeXKda4KrtcDFoPf-Zj2HicJ9w8=.8e445690-be8e-4fa0-b0c5-2509bac00c31@github.com>
 <Yx6NpJvPQwIHXTMKz9dhedWRlSPFfr_q2iVCMh_zmSU=.9aad94a9-45e9-4fb1-9b71-e6e87b9b2972@github.com>
 <3AyJ-64HfhxiD02r2iXCzQbadbuaTGXtcQqxi8R0PWY=.7023cba4-30d3-45de-a4eb-621538a9270f@github.com>
Message-ID: <DDXEs27eS5BEFMVQrSpEbKzLfol5otP8covgjB7jeRg=.7886886b-edb6-408d-9f18-5dd0aa0731d1@github.com>

On Fri, 25 Apr 2025 12:25:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Will do.

Great!

> The CSR could also be moved to "Proposed".

It was earlier today.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2830292381

From jpai at openjdk.org  Fri Apr 25 12:48:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Apr 2025 12:48:53 GMT
Subject: RFR: 8355370: Include server name in HTTP test server thread names
 to improve diagnostics [v2]
In-Reply-To: <m9tOBilckjtfBU6v4-Osr_3GEnUUgw70bEoFRAdqjDQ=.95127309-8fd9-48e7-87df-c568431f0524@github.com>
References: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
 <m9tOBilckjtfBU6v4-Osr_3GEnUUgw70bEoFRAdqjDQ=.95127309-8fd9-48e7-87df-c568431f0524@github.com>
Message-ID: <4_GUO7uqJigmCZ_sn_qhpkIcbAu2b_7wCIrxMjrGH2U=.5bdf06ff-7d7c-4313-857c-b2c395f8926b@github.com>

On Thu, 24 Apr 2025 07:24:36 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Incorporates the test server name while deriving the HTTP/2 test server (i.e., `jdk.httpclient.test.lib.http2.Http2TestServer`) thread names to improve diagnostics.
>> 
>> ### Making `HttpTestServer` implement `AutoCloseable`
>> 
>> I carried out this out-of-scope enhancement along with this PR, since this one-liner gives nice try-with-resources convenience while writing tests using HTTP test servers. Note that [this change is already implemented for the in-progress HTTP/3 work](/dfuch/jdk/blob/9c2da664d2875b7e7986831fd716d05b7a8306f4/test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java#L1119).
>> 
>> ### Improving HTTP/2 test server thread names
>> 
>> The HTTP/2 server thread names are improved by modifying the server default executor to include the HTTP/2 server name in its thread names. We deliberately did nothing for the HTTP/1.1 server (provided by the `jdk.httpserver` module). `ServerImpl`, the default HTTP/1.1 server implementation, has only one thread by default: the dispatcher and it is named `HTTP-Dispatcher`. Since factory methods in `com.sun.net.httpserver.Http[s]Server` don?t have the notion of a _name_, introducing a name would require a public API change.
>> Instead the calling code that creates the server can supply an Executor which creates threads with whatever name
>> is appropriate for the application/test.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix code typo
>  - Override `AutoCloseable::close` in `Http2TestServerImpl`

This looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24822#pullrequestreview-2794010166

From dfuchs at openjdk.org  Fri Apr 25 13:05:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Apr 2025 13:05:51 GMT
Subject: RFR: 8355370: Include server name in HTTP test server thread names
 to improve diagnostics [v2]
In-Reply-To: <m9tOBilckjtfBU6v4-Osr_3GEnUUgw70bEoFRAdqjDQ=.95127309-8fd9-48e7-87df-c568431f0524@github.com>
References: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
 <m9tOBilckjtfBU6v4-Osr_3GEnUUgw70bEoFRAdqjDQ=.95127309-8fd9-48e7-87df-c568431f0524@github.com>
Message-ID: <H3PDrE57K-YOK0h1teHnpks4_klBLA5I1nn2y4H5ApA=.f3637371-408b-4241-82cc-adbd407c47fa@github.com>

On Thu, 24 Apr 2025 07:24:36 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Incorporates the test server name while deriving the HTTP/2 test server (i.e., `jdk.httpclient.test.lib.http2.Http2TestServer`) thread names to improve diagnostics.
>> 
>> ### Making `HttpTestServer` implement `AutoCloseable`
>> 
>> I carried out this out-of-scope enhancement along with this PR, since this one-liner gives nice try-with-resources convenience while writing tests using HTTP test servers. Note that [this change is already implemented for the in-progress HTTP/3 work](/dfuch/jdk/blob/9c2da664d2875b7e7986831fd716d05b7a8306f4/test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java#L1119).
>> 
>> ### Improving HTTP/2 test server thread names
>> 
>> The HTTP/2 server thread names are improved by modifying the server default executor to include the HTTP/2 server name in its thread names. We deliberately did nothing for the HTTP/1.1 server (provided by the `jdk.httpserver` module). `ServerImpl`, the default HTTP/1.1 server implementation, has only one thread by default: the dispatcher and it is named `HTTP-Dispatcher`. Since factory methods in `com.sun.net.httpserver.Http[s]Server` don?t have the notion of a _name_, introducing a name would require a public API change.
>> Instead the calling code that creates the server can supply an Executor which creates threads with whatever name
>> is appropriate for the application/test.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix code typo
>  - Override `AutoCloseable::close` in `Http2TestServerImpl`

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24822#pullrequestreview-2794052203

From michaelm at openjdk.org  Fri Apr 25 14:26:43 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Apr 2025 14:26:43 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v8]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <gcSoUo3tWLNx0jsNON0D_X3_4nh3KYFsdCLHRIOZOWM=.edab27b1-73fc-4662-8e27-0c3889ef6b7e@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - doc + copyright update
 - remove file added by mistake
 - ... and 12 more: https://git.openjdk.org/jdk/compare/5c067232...9401d4c8

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=07
  Stats: 949 lines in 42 files changed: 716 ins; 101 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From pavel.rappo at gmail.com  Fri Apr 25 15:31:10 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Fri, 25 Apr 2025 16:31:10 +0100
Subject: HttpServer.stop seems to wait longer than expected
Message-ID: <CAChcVu=oE8rcA0MTe2dYQGpJ5u3aC9QzDLgTJ7vT2g6JmGGyQg@mail.gmail.com>

The specification of the method has these words (emphasis mine):

> The method will then block until all current exchange handlers have completed or else when approximately delay seconds have elapsed (__whichever happens sooner__).

I noticed that stop(t) blocks for approximately `t` seconds regardless
of whether there are any handlers being executed at the same time. I
thought that if there are no handlers being executed, `stop` would
return immediately. Did I misread the spec?

-Pavel

From daniel.fuchs at oracle.com  Fri Apr 25 15:55:57 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 25 Apr 2025 16:55:57 +0100
Subject: HttpServer.stop seems to wait longer than expected
In-Reply-To: <CAChcVu=oE8rcA0MTe2dYQGpJ5u3aC9QzDLgTJ7vT2g6JmGGyQg@mail.gmail.com>
References: <CAChcVu=oE8rcA0MTe2dYQGpJ5u3aC9QzDLgTJ7vT2g6JmGGyQg@mail.gmail.com>
Message-ID: <7d531279-255e-4b76-b021-4cdafc31c24a@oracle.com>

Hi Pavel,

No, it's a known bug:

https://bugs.openjdk.org/browse/JDK-8304065

best regards,

-- daniel

On 25/04/2025 16:31, Pavel Rappo wrote:
> The specification of the method has these words (emphasis mine):
> 
>> The method will then block until all current exchange handlers have completed or else when approximately delay seconds have elapsed (__whichever happens sooner__).
> 
> I noticed that stop(t) blocks for approximately `t` seconds regardless
> of whether there are any handlers being executed at the same time. I
> thought that if there are no handlers being executed, `stop` would
> return immediately. Did I misread the spec?
> 
> -Pavel


From dfuchs at openjdk.org  Fri Apr 25 17:10:59 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Apr 2025 17:10:59 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v10]
In-Reply-To: <alH_36iuDRDdDG3OvzXXbzQVlOMuh0zoH2Aqt9C6Z_8=.42317dbf-31ea-4ac8-b758-4a98f43737c3@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <alH_36iuDRDdDG3OvzXXbzQVlOMuh0zoH2Aqt9C6Z_8=.42317dbf-31ea-4ac8-b758-4a98f43737c3@github.com>
Message-ID: <sqN4yVKK2WkcLBDVe-3n-q4KjHjl_Dl-pQVYvUrB33c=.294c801b-4781-4584-9bb2-3da764869079@github.com>

On Fri, 25 Apr 2025 11:24:11 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
>> * Documents the new property in `net-properties.html` 
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s 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 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into disable-non-local-file-urls
>  - Add @comment referencing testing of non-local file URLs in NonLocalFtpFallback
>  - verifyNonLocalFileURLRejected is a better name for this test which expects the FTP fallback to be disabled
>  - Move testing of exceptional behavior of a non-local, FTP-fallback enabled file URL from OpenStream to NonLocalFtpFallback
>  - Add a test verifying that local file URLs such as 'file://localhost/folder/data.xml' are not affected by the FTP fallback feature being enabled
>  - Merge branch 'master' into disable-non-local-file-urls
>  - Fix repeated "should should"
>  - Move file URL properties out of the Proxy section, replace URI with URL
>  - Be explicit about explicit {@code ftp://} URIs
>  - Document jdk.net.file.ftpfallback as a Networking Property
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/80a4a3b2...af73727f

> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Hi Eirik, I have updated the wording of the release note at https://bugs.openjdk.org/browse/JDK-8354658 ; @AlanBateman or @Michael-Mc-Mahon may need to review my changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2830972728

From dfuchs at openjdk.org  Fri Apr 25 17:19:08 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Apr 2025 17:19:08 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v10]
In-Reply-To: <sqN4yVKK2WkcLBDVe-3n-q4KjHjl_Dl-pQVYvUrB33c=.294c801b-4781-4584-9bb2-3da764869079@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <alH_36iuDRDdDG3OvzXXbzQVlOMuh0zoH2Aqt9C6Z_8=.42317dbf-31ea-4ac8-b758-4a98f43737c3@github.com>
 <sqN4yVKK2WkcLBDVe-3n-q4KjHjl_Dl-pQVYvUrB33c=.294c801b-4781-4584-9bb2-3da764869079@github.com>
Message-ID: <USUmjTsRfvJdcaoXA4wRPvtXiBNjAPFFCr27DcRABh4=.eb028020-7efd-4c42-8412-5f14c1e1f061@github.com>

On Fri, 25 Apr 2025 17:08:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Eirik Bj?rsn?s 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 12 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into disable-non-local-file-urls
>>  - Add @comment referencing testing of non-local file URLs in NonLocalFtpFallback
>>  - verifyNonLocalFileURLRejected is a better name for this test which expects the FTP fallback to be disabled
>>  - Move testing of exceptional behavior of a non-local, FTP-fallback enabled file URL from OpenStream to NonLocalFtpFallback
>>  - Add a test verifying that local file URLs such as 'file://localhost/folder/data.xml' are not affected by the FTP fallback feature being enabled
>>  - Merge branch 'master' into disable-non-local-file-urls
>>  - Fix repeated "should should"
>>  - Move file URL properties out of the Proxy section, replace URI with URL
>>  - Be explicit about explicit {@code ftp://} URIs
>>  - Document jdk.net.file.ftpfallback as a Networking Property
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/8900fd62...af73727f
>
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
> 
> Hi Eirik, I have updated the wording of the release note at https://bugs.openjdk.org/browse/JDK-8354658 ; @AlanBateman or @Michael-Mc-Mahon may need to review my changes.

> @dfuch Would you consider giving these updated tests a spin on Oracle CI to verify?

The results came back green.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2830988048

From dfuchs at openjdk.org  Fri Apr 25 17:33:08 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Apr 2025 17:33:08 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v10]
In-Reply-To: <alH_36iuDRDdDG3OvzXXbzQVlOMuh0zoH2Aqt9C6Z_8=.42317dbf-31ea-4ac8-b758-4a98f43737c3@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <alH_36iuDRDdDG3OvzXXbzQVlOMuh0zoH2Aqt9C6Z_8=.42317dbf-31ea-4ac8-b758-4a98f43737c3@github.com>
Message-ID: <sMwP0ZgMv3HIfNq6t4mtSTdY_6-rkSmXaBQV6HqZn2M=.d9f0a2e3-d4d2-4721-9eed-ddeb220e77bb@github.com>

On Fri, 25 Apr 2025 11:24:11 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
>> * Documents the new property in `net-properties.html` 
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s 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 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into disable-non-local-file-urls
>  - Add @comment referencing testing of non-local file URLs in NonLocalFtpFallback
>  - verifyNonLocalFileURLRejected is a better name for this test which expects the FTP fallback to be disabled
>  - Move testing of exceptional behavior of a non-local, FTP-fallback enabled file URL from OpenStream to NonLocalFtpFallback
>  - Add a test verifying that local file URLs such as 'file://localhost/folder/data.xml' are not affected by the FTP fallback feature being enabled
>  - Merge branch 'master' into disable-non-local-file-urls
>  - Fix repeated "should should"
>  - Move file URL properties out of the Proxy section, replace URI with URL
>  - Be explicit about explicit {@code ftp://} URIs
>  - Document jdk.net.file.ftpfallback as a Networking Property
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/03e34e30...af73727f

Sorry - rewording the release note got me thinking again...

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 55:

> 53:             System.getProperty("jdk.net.file.ftpfallback", "false")
> 54:     );
> 55: 

Maybe we should use `Boolean.getBoolean("jdk.net.file.ftpfallback")` here.

test/jdk/sun/net/www/protocol/file/NonLocalFtpFallbackDisabled.java line 58:

> 56:         // We can use a fake host name here, no actual FTP request will be made
> 57:         String hostname = "remotehost";
> 58:         URL nonLocalURL = new URL("file", hostname, localURL.getFile());

Should we also check that `new URL("file", hostname, "").openConnection()` will throw MUE?

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

PR Review: https://git.openjdk.org/jdk/pull/24657#pullrequestreview-2794825750
PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2060628151
PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2060634329

From eirbjo at openjdk.org  Fri Apr 25 18:41:19 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 18:41:19 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v11]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <Zz4jhQl58DyLBTxyYbNdu2CwqHm0HXeZ3dO18uiyEEU=.a78b6746-a6bb-40d4-b1dd-090ac76234a0@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
> * Documents the new property in `net-properties.html` 
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Add test for MUE on non-local URL with an empty path component
 - Use Boolean::getBoolean

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/af73727f..a5620182

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=09-10

  Stats: 14 lines in 2 files changed: 9 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From eirbjo at openjdk.org  Fri Apr 25 18:41:20 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 18:41:20 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v10]
In-Reply-To: <sMwP0ZgMv3HIfNq6t4mtSTdY_6-rkSmXaBQV6HqZn2M=.d9f0a2e3-d4d2-4721-9eed-ddeb220e77bb@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <alH_36iuDRDdDG3OvzXXbzQVlOMuh0zoH2Aqt9C6Z_8=.42317dbf-31ea-4ac8-b758-4a98f43737c3@github.com>
 <sMwP0ZgMv3HIfNq6t4mtSTdY_6-rkSmXaBQV6HqZn2M=.d9f0a2e3-d4d2-4721-9eed-ddeb220e77bb@github.com>
Message-ID: <ytl8TbhpN-HabekduO4-k_68ka_H0KGzvq25UStzV2s=.701e4f1b-577a-44a3-9ac0-0df2b04b813f@github.com>

On Fri, 25 Apr 2025 17:30:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Sorry - rewording the release note got me thinking again...

Documentation Driven Development For The Win! ?

> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 55:
> 
>> 53:             System.getProperty("jdk.net.file.ftpfallback", "false")
>> 54:     );
>> 55: 
> 
> Maybe we should use `Boolean.getBoolean("jdk.net.file.ftpfallback")` here.

I think I did it this way because I wanted the default to be explicit. But, yes Boolean::getBoolean is short and sweet.

> test/jdk/sun/net/www/protocol/file/NonLocalFtpFallbackDisabled.java line 58:
> 
>> 56:         // We can use a fake host name here, no actual FTP request will be made
>> 57:         String hostname = "remotehost";
>> 58:         URL nonLocalURL = new URL("file", hostname, localURL.getFile());
> 
> Should we also check that `new URL("file", hostname, "").openConnection()` will throw MUE?

Not sure why, but can't think of a reason why not. So added that plus avoided the deprectated URL constructor.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2831152338
PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2060713939
PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2060714786

From eirbjo at openjdk.org  Fri Apr 25 18:41:20 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 18:41:20 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v5]
In-Reply-To: <lTL-BxrSBDdV3NwRerXrK8uBtc3pi_Idr9BI57DyH6s=.9d73e27b-7737-460b-92d9-f0345b2fb06a@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <kBehLI7dpnRgnGiQ6Bnt1iRQeTIAA18BJTYexrThEmM=.5b056218-01c4-4cbe-8d4f-3e498f77bbc7@github.com>
 <1d9UsH62o7LtENn3tSSsn06xKk29GOdPhiPeZMGtL7c=.e1c7f376-92b7-4c29-be29-e2e26f5ac89d@github.com>
 <lTL-BxrSBDdV3NwRerXrK8uBtc3pi_Idr9BI57DyH6s=.9d73e27b-7737-460b-92d9-f0345b2fb06a@github.com>
Message-ID: <LQjomPFVTqy6I0S6ffm82fWbwE5BTJD1OSQhurXBp6w=.29a0a808-7894-4350-851d-4c36c547691a@github.com>

On Wed, 23 Apr 2025 17:04:30 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/doc-files/net-properties.html line 174:
>> 
>>> 172: <a id="FileHandler"></a>
>>> 173: <H2>File URL stream protocol handler properties</H2>
>>> 174: <P>The following properties are used to configure the handler for URLs with the {@code file://} scheme:</P>
>> 
>> I wonder if it should say the `{@code file:}` scheme instead. Although I understand that the case that interests us here is "file://some.host/some/path". Don't change anything right now - let's see if we have other opinions.
>
>> I wonder if it should say the `{@code file:}` scheme instead. 
> 
> This seems like an improvement to me. Not really a deliberate choice to include the slashes on my part, probably more for consistency with other schemes under Proxy. Files with any host component should be a rarity.
> 
>> Don't change anything right now - let's see if we have other opinions.
> 
> Sure, we can let this simmer a bit.

> I wonder if it should say the `{@code file:}` scheme instead. Although I understand that the case that interests us here is "file://some.host/some/path". Don't change anything right now - let's see if we have other opinions.

Nobody commented on this. Should we keep the slashes - or slash them?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2060717455

From dfuchs at openjdk.org  Fri Apr 25 18:51:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Apr 2025 18:51:53 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v11]
In-Reply-To: <Zz4jhQl58DyLBTxyYbNdu2CwqHm0HXeZ3dO18uiyEEU=.a78b6746-a6bb-40d4-b1dd-090ac76234a0@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Zz4jhQl58DyLBTxyYbNdu2CwqHm0HXeZ3dO18uiyEEU=.a78b6746-a6bb-40d4-b1dd-090ac76234a0@github.com>
Message-ID: <E6F4vS89eDOt3p708vWADnRsBC1BZCWS3N0HKoC5Ado=.305092a3-380d-425e-b52a-ba113db24944@github.com>

On Fri, 25 Apr 2025 18:41:19 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
>> 
>> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
>> 
>> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
>> 
>> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
>> 
>> This PR:
>> 
>> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
>> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
>> * Documents the new property in `net-properties.html` 
>> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
>> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
>> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
>> 
>> I have added a Release Note as a subtask in the JBS issue, this also needs a review.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add test for MUE on non-local URL with an empty path component
>  - Use Boolean::getBoolean

test/jdk/sun/net/www/protocol/file/NonLocalFtpFallbackDisabled.java line 62:

> 60:             // Non-empty path
> 61:             URL localURL = file.toUri().toURL();
> 62:             URL nonLocalURL = new URI("file", hostname, localURL.getFile(), "").toURL();

Actually we should take that out of the assertThrows since MalformedURLException could be thrown while constructing the URL...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2060730678

From eirbjo at openjdk.org  Fri Apr 25 18:56:36 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 18:56:36 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v12]
In-Reply-To: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
Message-ID: <LAgWwvYwL1-tXHAjg59HnbyUSDTNRZKDPimciOGuy80=.5221050f-d18c-4d0b-8817-3146c178fa1c@github.com>

> Please help review this PR which disables the unspecified but long-standing feature where an `FtpURLConnection` is opened as a fallback for non-local file URLs.
> 
> Before this change, if a file URL has a non-local host component, say `file://remotehost/folder/data.txt`, then the  implementation would attempt opening an FTP connection to `remotehost`. After this change, such URLs will be rejected with a `MalformedURLException`, unless the FTP fallback feature is explicitly re-enabled via a system property.
> 
> This change was initially discussed here: https://mail.openjdk.org/pipermail/net-dev/2025-March/025988.html
> 
> See the above discussion and CSR draft JDK-8354678 for the motivation for this change.
> 
> This PR:
> 
> * Changes file URL `Handler::openConnection` implementation for unix/windows to throw `MalformedURLException`, unless the FTP fallback feature is explicitly enabled by configuration.
> * Introduces a new system property `jdk.net.file.ftpenabled` which when set to `true` re-enables the feature.
> * Documents the new property in `net-properties.html` 
> * Updates the existing test `NonLocalFtpFallback` to enable the feature via said system property.
> * Adds a new test `NonLocalFtpFallbackDisabled` verifying that a `MalformedURLException` is thrown by default for a non-local URL host component.
> * Moves testing of exceptional behavior in FtpConnection when using non-local file URLs with FTP fallback enabled from `OpenStream` to `NonLocalFtpFallback`
> 
> I have added a Release Note as a subtask in the JBS issue, this also needs a review.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Move URL construction out of assertThrows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24657/files
  - new: https://git.openjdk.org/jdk/pull/24657/files/a5620182..8eac2ffd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24657&range=10-11

  Stats: 15 lines in 1 file changed: 7 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24657/head:pull/24657

PR: https://git.openjdk.org/jdk/pull/24657

From eirbjo at openjdk.org  Fri Apr 25 18:56:36 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 25 Apr 2025 18:56:36 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v11]
In-Reply-To: <E6F4vS89eDOt3p708vWADnRsBC1BZCWS3N0HKoC5Ado=.305092a3-380d-425e-b52a-ba113db24944@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <Zz4jhQl58DyLBTxyYbNdu2CwqHm0HXeZ3dO18uiyEEU=.a78b6746-a6bb-40d4-b1dd-090ac76234a0@github.com>
 <E6F4vS89eDOt3p708vWADnRsBC1BZCWS3N0HKoC5Ado=.305092a3-380d-425e-b52a-ba113db24944@github.com>
Message-ID: <thG4QYecs9NIeewjf45WM649vI1lX8U8gYoZXtqZN0U=.25b93244-428f-4ed7-9d5d-3f37f0fec617@github.com>

On Fri, 25 Apr 2025 18:48:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> MalformedURLException could be thrown while constructing the URL...

Good catch, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24657#discussion_r2060739140

From abarashev at openjdk.org  Fri Apr 25 19:09:55 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:09:55 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: <VK3OPea665iZC9L0afD3lLokdgrTbNj_kbiYZFe2Xf8=.885395b6-9daa-421b-8c5a-09722b236052@github.com>

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 192:

> 190:      */
> 191:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
> 192:                                         String[] allowedAlgorithms,

This should probably be renamed to `supportedAlgorithms` for consistency, to match SSLEngine and SSLSocket methods.

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

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

From abarashev at openjdk.org  Fri Apr 25 19:15:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:15:59 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: <d-C3dWGfCTMMvUNSJEasqpki3hPXsceVRq1Zcvk1ELs=.786376c8-68d2-48f7-8d8c-3a960d44d610@github.com>

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 172:

> 170:             userSpecifiedConstraints = engine.getSSLParameters()
> 171:                     .getAlgorithmConstraints();
> 172:         }

Duplicate code block here and in the 2nd `forQUIC` method. We should move it to a private `getUserSpecifiedConstraints` method, like in SSLEngine and SSLSocket cases. In fact I think all 3 methods could be combined into a single `getUserSpecifiedConstraints(Object o)` since they all do the same thing.

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

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

From abarashev at openjdk.org  Fri Apr 25 19:33:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:33:00 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: <04qyL7y-HmZj4Z_m1tc--rIZHU9aJlczhSGBQCVkWxc=.b4f05b83-6166-479f-871b-cfd03c00d9f6@github.com>

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 275:

> 273:         final X509Certificate[] trustedChain = v.validate(chain, null,
> 274:                 responseList, constraints, authType);
> 275:         if (sslParameters != null && handshakeSession != null) {

Looks like this `if` block is not needed: `sslParameters != null` condition is always `true`, and we should throw an exception in the beginning of the method if session is null.

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

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

From abarashev at openjdk.org  Fri Apr 25 19:45:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:45:00 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: <sWlJhX9smaVlYnJXwnhev6rXJBTEgIackPrRITGTs9g=.efaa1edf-d0fe-4c6b-8205-a20ae68adcc0@github.com>

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 532:

> 530:     }
> 531: 
> 532:     public boolean isQuic() {

This method never called.

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

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

From josiahnoel at gmail.com  Fri Apr 25 20:47:55 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Fri, 25 Apr 2025 16:47:55 -0400
Subject: Range header support
Message-ID: <CAJ_t5Ubph7j2yauqgzk04H_gJ34nhyH6zHmBANzy+_mJEG_T=g@mail.gmail.com>

I present for your consideration the kind of logic I normally use for range
requests with the jdk.httpserver. It can resume downloads and properly
stream video to the browser.


 Link to Gist
<https://gist.github.com/SentryMan/cd59bfecd55fa0e0c9244d390c175f9f>

-- 
Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250425/5185793e/attachment.htm>

From josiahnoel at gmail.com  Fri Apr 25 22:05:42 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Fri, 25 Apr 2025 18:05:42 -0400
Subject: Range header support
Message-ID: <CAJ_t5Ub24k5rk-CjpeCyWamExhZSDUDkGrVFdE=y9Tc5Y5=HUw@mail.gmail.com>

I should mention that the code I posted may not work well with the default
single-threaded executor, as the browser's barrage of range requests could
cause the server to lock up. I normally use a virtual thread executor,
so the chunk size would need a second look if we want to stay with the
single-threaded executor.

-- 
Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250425/293e0050/attachment.htm>

From michaelm at openjdk.org  Mon Apr 28 09:24:52 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 28 Apr 2025 09:24:52 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v10]
In-Reply-To: <sqN4yVKK2WkcLBDVe-3n-q4KjHjl_Dl-pQVYvUrB33c=.294c801b-4781-4584-9bb2-3da764869079@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <alH_36iuDRDdDG3OvzXXbzQVlOMuh0zoH2Aqt9C6Z_8=.42317dbf-31ea-4ac8-b758-4a98f43737c3@github.com>
 <sqN4yVKK2WkcLBDVe-3n-q4KjHjl_Dl-pQVYvUrB33c=.294c801b-4781-4584-9bb2-3da764869079@github.com>
Message-ID: <pix9LZ4OTrpnMplaDSo-FEXRElFJueNHAFHdhHvEAps=.37c9ed43-1b35-47e9-b7e9-26503ce59e49@github.com>

On Fri, 25 Apr 2025 17:08:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > I have added a Release Note as a subtask in the JBS issue, this also needs a review.
> 
> Hi Eirik, I have updated the wording of the release note at https://bugs.openjdk.org/browse/JDK-8354658 ; @AlanBateman or @Michael-Mc-Mahon may need to review my changes.

I fixed a few typos. Otherwise, it looks good.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2834576077

From pavel.rappo at gmail.com  Sun Apr 27 15:11:06 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Sun, 27 Apr 2025 16:11:06 +0100
Subject: New convenience HttpHandler
Message-ID: <CAChcVu=Swc_PM2w55jxw5s=NmancKa4ooiEuxyePTZ1g-8mUQA@mail.gmail.com>

I'm using HttpServer to implement an HTTP probe [^1] that provides
application state at the time of probing. I find that convenience
handlers provided by HttpHandlers are insufficient for my use case. I
also find that implementing a custom HttpHandler is tricky without the
help of documentation.

Perhaps my use case is typical enough so that HttpHandlers could
provide a new convenience handler. That handler would send a
dynamically supplied string, rather than a static string. If you also
find it useful, I'd appreciate it if we could discuss it. Before I
create a JBS issue, please have a look at this crude patch to see if
it makes sense to you in principle. Thanks.

[^1]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

diff --git a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
index 03642033914..987de0ede5d 100644
--- a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
+++ b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
@@ -25,9 +25,11 @@

 package com.sun.net.httpserver;

+import java.io.OutputStream;
 import java.nio.charset.StandardCharsets;
 import java.util.Objects;
 import java.util.function.Predicate;
+import java.util.function.Supplier;

 /**
  * Implementations of {@link com.sun.net.httpserver.HttpHandler HttpHandler}
@@ -140,28 +142,60 @@ public static HttpHandler
handleOrElse(Predicate<Request> handlerTest,
      * @throws NullPointerException     if headers or body are null
      */
     public static HttpHandler of(int statusCode, Headers headers,
String body) {
+        Objects.requireNonNull(body);
+        return of(statusCode, headers, () -> body);
+    }
+
+    /**
+     * Returns an {@code HttpHandler} that sends a response
comprising the given
+     * {@code statusCode}, {@code headers}, and {@code body}.
+     *
+     * <p> This method creates a handler that reads and discards the request
+     * body before it sets the response state and sends the response.
+     *
+     * <p> {@code headers} are the effective headers of the response. The
+     * response <i>body bytes</i> are a {@code UTF-8} encoded byte sequence of
+     * a string, which is supplied by {@code bodySupplier}
immediately after the request body is read. The response headers
+     * {@linkplain HttpExchange#sendResponseHeaders(int, long) are sent} with
+     * the given {@code statusCode} and the body bytes' length (or {@code -1}
+     * if the body is empty). The body bytes are then sent as response body,
+     * unless the body is empty, in which case no response body is sent.
+     *
+     * @param statusCode a response status code
+     * @param headers a headers
+     * @param bodySupplier a supplier for the response body string
+     * @return a handler
+     * @throws IllegalArgumentException if statusCode is not a positive 3-digit
+     *                                  integer, as per rfc2616, section 6.1.1
+     * @throws NullPointerException     if headers or body are null
+     */
+    public static HttpHandler of(int statusCode, Headers headers,
Supplier<String> bodySupplier) {
         if (statusCode < 100 || statusCode > 999)
             throw new IllegalArgumentException("statusCode must be 3-digit: "
                     + statusCode);
         Objects.requireNonNull(headers);
-        Objects.requireNonNull(body);
+        Objects.requireNonNull(bodySupplier);

         final var headersCopy = Headers.of(headers);
-        final var bytes = body.getBytes(StandardCharsets.UTF_8);

         return exchange -> {
             try (exchange) {
-                exchange.getRequestBody().readAllBytes();
+
exchange.getRequestBody().transferTo(OutputStream.nullOutputStream());
// discard
                 exchange.getResponseHeaders().putAll(headersCopy);
-                if (exchange.getRequestMethod().equals("HEAD")) {
-
exchange.getResponseHeaders().set("Content-Length",
Integer.toString(bytes.length));
-                    exchange.sendResponseHeaders(statusCode, -1);
-                }
-                else if (bytes.length == 0) {
-                    exchange.sendResponseHeaders(statusCode, -1);
+                var body = bodySupplier.get();
+                if (body == null) {
+                    exchange.sendResponseHeaders(500, -1); //
Internal Server Error
                 } else {
-                    exchange.sendResponseHeaders(statusCode, bytes.length);
-                    exchange.getResponseBody().write(bytes);
+                    final var bytes = body.getBytes(StandardCharsets.UTF_8);
+                    if (exchange.getRequestMethod().equals("HEAD")) {
+
exchange.getResponseHeaders().set("Content-Length",
Integer.toString(bytes.length));
+                        exchange.sendResponseHeaders(statusCode, -1);
+                    } else if (bytes.length == 0) {
+                        exchange.sendResponseHeaders(statusCode, -1);
+                    } else {
+                        exchange.sendResponseHeaders(statusCode, bytes.length);
+                        exchange.getResponseBody().write(bytes);
+                    }
                 }
             }
         };
diff --git a/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
b/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
index 85d271e44fa..d64fa03740f 100644
--- a/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
+++ b/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
@@ -81,7 +81,7 @@ public void testNull() {
         final var headers = new Headers();
         final var body = "";
         assertThrows(NPE, () -> HttpHandlers.of(200, null, body));
-        assertThrows(NPE, () -> HttpHandlers.of(200, headers, null));
+        assertThrows(NPE, () -> HttpHandlers.of(200, headers, (String) null));
     }

     @Test

From dfuchs at openjdk.org  Mon Apr 28 14:07:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Apr 2025 14:07:50 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v4]
In-Reply-To: <qxpuO5Luok2GIOJK3J3ltC-BksqJG13rFKyWkSPSWUM=.89c6e06d-9273-409d-a747-83b22c113303@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <qxpuO5Luok2GIOJK3J3ltC-BksqJG13rFKyWkSPSWUM=.89c6e06d-9273-409d-a747-83b22c113303@github.com>
Message-ID: <NlkVgCJETAlUjDezJMZftWMIQYDMh835RYP3b2x4pOc=.ae11a6f3-d17f-4335-92a2-a9bb2c44d455@github.com>

On Thu, 10 Apr 2025 16:35:01 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix whitespace
>  - Use ProtocolException for malformed headers

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 988:

> 986:                     // connection-level HPACK decoding state
> 987:                     if (orphanedConsumer == null || frame.getClass() != ContinuationFrame.class) {
> 988:                         orphanedConsumer = new ValidatingHeadersConsumer(Context.RESPONSE);

Should the context be `Context.REQUEST` if `hf instanceof PushPromiseFrame`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2063733675

From jpai at openjdk.org  Mon Apr 28 14:16:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Apr 2025 14:16:51 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v4]
In-Reply-To: <qxpuO5Luok2GIOJK3J3ltC-BksqJG13rFKyWkSPSWUM=.89c6e06d-9273-409d-a747-83b22c113303@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <qxpuO5Luok2GIOJK3J3ltC-BksqJG13rFKyWkSPSWUM=.89c6e06d-9273-409d-a747-83b22c113303@github.com>
Message-ID: <1TAycTK47_BToDvYym_3uBudSKDPa_KzZ3AUryIFMBk=.f4cf7f63-1066-46d6-b77b-ed0a8f3cafb2@github.com>

On Thu, 10 Apr 2025 16:35:01 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix whitespace
>  - Use ProtocolException for malformed headers

src/java.net.http/share/classes/jdk/internal/net/http/common/HeaderDecoder.java line 34:

> 32: 
> 33:     public HeaderDecoder() {
> 34:         super(Context.REQUEST);

It feels a bit odd that a header "decoder" is being used in the context of a request. I then looked at the references of this class and I see that the only place this gets used/instantiated is in the `PushPromiseDecoder` and it then makes sense why the context used here is `REQUEST`. 

Do you think it would be better if we changed this `HeaderDecoder` constructor to accept a `Context` param and then have `PushPromiseDecoder` pass it the `Context.REQUEST`? That way it's a bit more clear at the use site, in PushPromiseDecoder, why `Context.REQUEST` gets used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2063756842

From jpai at openjdk.org  Mon Apr 28 14:24:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Apr 2025 14:24:51 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v4]
In-Reply-To: <qxpuO5Luok2GIOJK3J3ltC-BksqJG13rFKyWkSPSWUM=.89c6e06d-9273-409d-a747-83b22c113303@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <qxpuO5Luok2GIOJK3J3ltC-BksqJG13rFKyWkSPSWUM=.89c6e06d-9273-409d-a747-83b22c113303@github.com>
Message-ID: <erur0tFYa7W5A9JSKPjetuQclk9RnNEd5wpt-N3nj2w=.8bab1a6b-aa36-4fb3-9ec6-0713d10e78d6@github.com>

On Thu, 10 Apr 2025 16:35:01 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix whitespace
>  - Use ProtocolException for malformed headers

src/java.net.http/share/classes/jdk/internal/net/http/common/ValidatingHeadersConsumer.java line 41:

> 39: 
> 40:     public ValidatingHeadersConsumer(Context context) {
> 41:         this.context = context;

Nit - we should probably disallow `null` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2063774255

From jpai at openjdk.org  Mon Apr 28 14:35:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Apr 2025 14:35:57 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v4]
In-Reply-To: <qxpuO5Luok2GIOJK3J3ltC-BksqJG13rFKyWkSPSWUM=.89c6e06d-9273-409d-a747-83b22c113303@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <qxpuO5Luok2GIOJK3J3ltC-BksqJG13rFKyWkSPSWUM=.89c6e06d-9273-409d-a747-83b22c113303@github.com>
Message-ID: <ijTewnwEkzn2AOCZx1tBLVW0LlwLnEoOFDiwxajZt4w=.01f574b3-7b50-4fe8-bc44-213a275f0555@github.com>

On Thu, 10 Apr 2025 16:35:01 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix whitespace
>  - Use ProtocolException for malformed headers

test/jdk/java/net/httpclient/http2/BadHeadersTest.java line 30:

> 28:  * @build jdk.httpclient.test.lib.http2.Http2TestServer jdk.test.lib.net.SimpleSSLContext
> 29:  * @run testng/othervm -Djdk.internal.httpclient.debug=true BadHeadersTest
> 30:  * @summary This test verifies the behaviour of the HttpClient when presented

Nit - the jtreg tag ordering guideline recommends adding `@summary` after the `@bug` line https://openjdk.org/jtreg/tag-spec.html#ORDER.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2063795188

From alanb at openjdk.org  Mon Apr 28 14:57:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Apr 2025 14:57:49 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v8]
In-Reply-To: <gcSoUo3tWLNx0jsNON0D_X3_4nh3KYFsdCLHRIOZOWM=.edab27b1-73fc-4662-8e27-0c3889ef6b7e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <gcSoUo3tWLNx0jsNON0D_X3_4nh3KYFsdCLHRIOZOWM=.edab27b1-73fc-4662-8e27-0c3889ef6b7e@github.com>
Message-ID: <JsOTWBsT2fbZGPScefJJul8a2VWcDKgE0gdIiZ_GHR4=.72cd6616-2191-411a-aa07-4910eaaefb7d@github.com>

On Fri, 25 Apr 2025 14:26:43 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - update to minimise code changes
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    from turbanoff review
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - doc + copyright update
>  - remove file added by mistake
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/5c067232...9401d4c8

src/java.base/share/conf/security/java.security line 1311:

> 1309: #  hostInfo - Special value which signifies the three categories above combined
> 1310: #             (socket, addressLookup, net). This is provided for compatibility
> 1311: #             with previous releases.

Are you sure "socket", "addressLookup", and "net" categories are useful and needed? I would think someone configuring this is looking to keeping sensitive fields out of the exception messages without knowing exactly which APIs are used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2063849188

From mullan at openjdk.org  Mon Apr 28 18:59:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Apr 2025 18:59:53 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <xNTKNw56qEiRc6oU_NMnWtbD1V4FRpC63waNCUm9jdQ=.8b434d7c-8c96-42f9-8e37-4d06651da4a4@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
 <rVqCd_DVMFQ-IvM8H3_h26LN-rcuKon-Zv8ZA-g2t3I=.a55a3fcf-f219-4127-b3df-278534230389@github.com>
 <HICWfI_yKD64mMPhIsGHFT5cPIw4Az-RociRzPvJUXQ=.d3150052-6cb2-486a-b149-5b5617c183d3@github.com>
 <xNTKNw56qEiRc6oU_NMnWtbD1V4FRpC63waNCUm9jdQ=.8b434d7c-8c96-42f9-8e37-4d06651da4a4@github.com>
Message-ID: <M2N2txL2370OJ-NMxgkQ_qC15SC8cUbhTcFKo--AiP4=.45b41468-c1d9-4378-ac74-48a467113baf@github.com>

On Wed, 23 Apr 2025 13:07:31 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> A lot of (existing) HttpClient tests in `test/jdk/java/net/httpclient` currently use this `SimpleSSLContext` construct to read the `testkeys` keystore that's available in the JDK repo's test directory. Moving to a dynamically created keystore instead of a keystore that's committed in the JDK repo seems reasonable. I think it would be better to do that as a separate task in future, since that would involve updating these existing tests to use this new mechanism too.
>
> Sounds good, this was just FYI.

I may be wrong, but it seems you only re-enable 3DES to test a non-TLS 1.3 cipher suite. But you don't have to use a 3DES suite to do that, you could use one of the suites that are already enabled (and are still considered strong), like "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256".

As a general comment, I would avoid re-enabling broken or disabled algorithms unless you specifically have to test that algorithm for some reason.

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

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

From mullan at openjdk.org  Mon Apr 28 18:59:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Apr 2025 18:59:56 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: <MQP9ydYlNHaWHQMfVjWUnVXaB8To0aV9rSXgT1Pad_M=.84b03782-6aa0-4a21-85e1-3c59d7e9c7bc@github.com>

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 130:

> 128:                             + "expect UnsupportedProtocolVersionException",
> 129:                     () -> connect(uriString, new SSLParameters(
> 130:                             new String[] { "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA" },

Shouldn't this be "TLS_AES_128_GCM_SHA256" (per the test comment above)?

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

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

From ethan at mccue.dev  Mon Apr 28 19:53:30 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 28 Apr 2025 15:53:30 -0400
Subject: New convenience HttpHandler
In-Reply-To: <CAChcVu=Swc_PM2w55jxw5s=NmancKa4ooiEuxyePTZ1g-8mUQA@mail.gmail.com>
References: <CAChcVu=Swc_PM2w55jxw5s=NmancKa4ooiEuxyePTZ1g-8mUQA@mail.gmail.com>
Message-ID: <CA+NR86jNCUGrups_YTbXbmKQpYfiChDZbP0hJbgzhDUQx1_h3g@mail.gmail.com>

My first thought is that if you are computing the string maybe you'd want
to look at the request. Or set a header for content type.

I'm not going to push hard until valhalla is at least in preview (+ we've
already talked it to death) but a Body abstraction would probably
solve your use-case more robustly than yet another method there.

exchange -> exchange.sendResponse(200, Body.of("example"));

On Mon, Apr 28, 2025 at 5:28?AM Pavel Rappo <pavel.rappo at gmail.com> wrote:

> I'm using HttpServer to implement an HTTP probe [^1] that provides
> application state at the time of probing. I find that convenience
> handlers provided by HttpHandlers are insufficient for my use case. I
> also find that implementing a custom HttpHandler is tricky without the
> help of documentation.
>
> Perhaps my use case is typical enough so that HttpHandlers could
> provide a new convenience handler. That handler would send a
> dynamically supplied string, rather than a static string. If you also
> find it useful, I'd appreciate it if we could discuss it. Before I
> create a JBS issue, please have a look at this crude patch to see if
> it makes sense to you in principle. Thanks.
>
> [^1]:
> https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
>
> diff --git
> a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
> b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
> index 03642033914..987de0ede5d 100644
> ---
> a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
> +++
> b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
> @@ -25,9 +25,11 @@
>
>  package com.sun.net.httpserver;
>
> +import java.io.OutputStream;
>  import java.nio.charset.StandardCharsets;
>  import java.util.Objects;
>  import java.util.function.Predicate;
> +import java.util.function.Supplier;
>
>  /**
>   * Implementations of {@link com.sun.net.httpserver.HttpHandler
> HttpHandler}
> @@ -140,28 +142,60 @@ public static HttpHandler
> handleOrElse(Predicate<Request> handlerTest,
>       * @throws NullPointerException     if headers or body are null
>       */
>      public static HttpHandler of(int statusCode, Headers headers,
> String body) {
> +        Objects.requireNonNull(body);
> +        return of(statusCode, headers, () -> body);
> +    }
> +
> +    /**
> +     * Returns an {@code HttpHandler} that sends a response
> comprising the given
> +     * {@code statusCode}, {@code headers}, and {@code body}.
> +     *
> +     * <p> This method creates a handler that reads and discards the
> request
> +     * body before it sets the response state and sends the response.
> +     *
> +     * <p> {@code headers} are the effective headers of the response. The
> +     * response <i>body bytes</i> are a {@code UTF-8} encoded byte
> sequence of
> +     * a string, which is supplied by {@code bodySupplier}
> immediately after the request body is read. The response headers
> +     * {@linkplain HttpExchange#sendResponseHeaders(int, long) are sent}
> with
> +     * the given {@code statusCode} and the body bytes' length (or {@code
> -1}
> +     * if the body is empty). The body bytes are then sent as response
> body,
> +     * unless the body is empty, in which case no response body is sent.
> +     *
> +     * @param statusCode a response status code
> +     * @param headers a headers
> +     * @param bodySupplier a supplier for the response body string
> +     * @return a handler
> +     * @throws IllegalArgumentException if statusCode is not a positive
> 3-digit
> +     *                                  integer, as per rfc2616, section
> 6.1.1
> +     * @throws NullPointerException     if headers or body are null
> +     */
> +    public static HttpHandler of(int statusCode, Headers headers,
> Supplier<String> bodySupplier) {
>          if (statusCode < 100 || statusCode > 999)
>              throw new IllegalArgumentException("statusCode must be
> 3-digit: "
>                      + statusCode);
>          Objects.requireNonNull(headers);
> -        Objects.requireNonNull(body);
> +        Objects.requireNonNull(bodySupplier);
>
>          final var headersCopy = Headers.of(headers);
> -        final var bytes = body.getBytes(StandardCharsets.UTF_8);
>
>          return exchange -> {
>              try (exchange) {
> -                exchange.getRequestBody().readAllBytes();
> +
> exchange.getRequestBody().transferTo(OutputStream.nullOutputStream());
> // discard
>                  exchange.getResponseHeaders().putAll(headersCopy);
> -                if (exchange.getRequestMethod().equals("HEAD")) {
> -
> exchange.getResponseHeaders().set("Content-Length",
> Integer.toString(bytes.length));
> -                    exchange.sendResponseHeaders(statusCode, -1);
> -                }
> -                else if (bytes.length == 0) {
> -                    exchange.sendResponseHeaders(statusCode, -1);
> +                var body = bodySupplier.get();
> +                if (body == null) {
> +                    exchange.sendResponseHeaders(500, -1); //
> Internal Server Error
>                  } else {
> -                    exchange.sendResponseHeaders(statusCode,
> bytes.length);
> -                    exchange.getResponseBody().write(bytes);
> +                    final var bytes =
> body.getBytes(StandardCharsets.UTF_8);
> +                    if (exchange.getRequestMethod().equals("HEAD")) {
> +
> exchange.getResponseHeaders().set("Content-Length",
> Integer.toString(bytes.length));
> +                        exchange.sendResponseHeaders(statusCode, -1);
> +                    } else if (bytes.length == 0) {
> +                        exchange.sendResponseHeaders(statusCode, -1);
> +                    } else {
> +                        exchange.sendResponseHeaders(statusCode,
> bytes.length);
> +                        exchange.getResponseBody().write(bytes);
> +                    }
>                  }
>              }
>          };
> diff --git
> a/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
> b/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
> index 85d271e44fa..d64fa03740f 100644
> --- a/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
> +++ b/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
> @@ -81,7 +81,7 @@ public void testNull() {
>          final var headers = new Headers();
>          final var body = "";
>          assertThrows(NPE, () -> HttpHandlers.of(200, null, body));
> -        assertThrows(NPE, () -> HttpHandlers.of(200, headers, null));
> +        assertThrows(NPE, () -> HttpHandlers.of(200, headers, (String)
> null));
>      }
>
>      @Test
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250428/164f24b2/attachment-0001.htm>

From pavel.rappo at gmail.com  Mon Apr 28 21:35:50 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Mon, 28 Apr 2025 22:35:50 +0100
Subject: New convenience HttpHandler
In-Reply-To: <CA+NR86jNCUGrups_YTbXbmKQpYfiChDZbP0hJbgzhDUQx1_h3g@mail.gmail.com>
References: <CAChcVu=Swc_PM2w55jxw5s=NmancKa4ooiEuxyePTZ1g-8mUQA@mail.gmail.com>
 <CA+NR86jNCUGrups_YTbXbmKQpYfiChDZbP0hJbgzhDUQx1_h3g@mail.gmail.com>
Message-ID: <CAChcVunDyYveSuKZQwGKdMPQiREMrCF+VUT+hw-GSGsm05PapQ@mail.gmail.com>

You are right that a function would be more general than a supplier.
That crossed my mind too. However, here, with greater generality comes
less convenience. Like with your example, don't you need to read a
request body and then finally close the exchange? Perhaps that can be
solved with better documentation rather than one more convenience
method. Perhaps documentation could provide (a snippet of) a skeletal
implementation of a handler.

Also, even the "static string" convenience handler is problematic: no
one sets the content type because it's unknown: the passed string can
be HTML, JSON, plain text or what have you. And no one sets the
character encoding because (AFAIK) it only comes with the content type
and not on its own.

On Mon, Apr 28, 2025 at 8:53?PM Ethan McCue <ethan at mccue.dev> wrote:
>
> My first thought is that if you are computing the string maybe you'd want to look at the request. Or set a header for content type.
>
> I'm not going to push hard until valhalla is at least in preview (+ we've already talked it to death) but a Body abstraction would probably solve your use-case more robustly than yet another method there.
>
> exchange -> exchange.sendResponse(200, Body.of("example"));
>
> On Mon, Apr 28, 2025 at 5:28?AM Pavel Rappo <pavel.rappo at gmail.com> wrote:
>>
>> I'm using HttpServer to implement an HTTP probe [^1] that provides
>> application state at the time of probing. I find that convenience
>> handlers provided by HttpHandlers are insufficient for my use case. I
>> also find that implementing a custom HttpHandler is tricky without the
>> help of documentation.
>>
>> Perhaps my use case is typical enough so that HttpHandlers could
>> provide a new convenience handler. That handler would send a
>> dynamically supplied string, rather than a static string. If you also
>> find it useful, I'd appreciate it if we could discuss it. Before I
>> create a JBS issue, please have a look at this crude patch to see if
>> it makes sense to you in principle. Thanks.
>>
>> [^1]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
>>
>> diff --git a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>> b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>> index 03642033914..987de0ede5d 100644
>> --- a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>> +++ b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>> @@ -25,9 +25,11 @@
>>
>>  package com.sun.net.httpserver;
>>
>> +import java.io.OutputStream;
>>  import java.nio.charset.StandardCharsets;
>>  import java.util.Objects;
>>  import java.util.function.Predicate;
>> +import java.util.function.Supplier;
>>
>>  /**
>>   * Implementations of {@link com.sun.net.httpserver.HttpHandler HttpHandler}
>> @@ -140,28 +142,60 @@ public static HttpHandler
>> handleOrElse(Predicate<Request> handlerTest,
>>       * @throws NullPointerException     if headers or body are null
>>       */
>>      public static HttpHandler of(int statusCode, Headers headers,
>> String body) {
>> +        Objects.requireNonNull(body);
>> +        return of(statusCode, headers, () -> body);
>> +    }
>> +
>> +    /**
>> +     * Returns an {@code HttpHandler} that sends a response
>> comprising the given
>> +     * {@code statusCode}, {@code headers}, and {@code body}.
>> +     *
>> +     * <p> This method creates a handler that reads and discards the request
>> +     * body before it sets the response state and sends the response.
>> +     *
>> +     * <p> {@code headers} are the effective headers of the response. The
>> +     * response <i>body bytes</i> are a {@code UTF-8} encoded byte sequence of
>> +     * a string, which is supplied by {@code bodySupplier}
>> immediately after the request body is read. The response headers
>> +     * {@linkplain HttpExchange#sendResponseHeaders(int, long) are sent} with
>> +     * the given {@code statusCode} and the body bytes' length (or {@code -1}
>> +     * if the body is empty). The body bytes are then sent as response body,
>> +     * unless the body is empty, in which case no response body is sent.
>> +     *
>> +     * @param statusCode a response status code
>> +     * @param headers a headers
>> +     * @param bodySupplier a supplier for the response body string
>> +     * @return a handler
>> +     * @throws IllegalArgumentException if statusCode is not a positive 3-digit
>> +     *                                  integer, as per rfc2616, section 6.1.1
>> +     * @throws NullPointerException     if headers or body are null
>> +     */
>> +    public static HttpHandler of(int statusCode, Headers headers,
>> Supplier<String> bodySupplier) {
>>          if (statusCode < 100 || statusCode > 999)
>>              throw new IllegalArgumentException("statusCode must be 3-digit: "
>>                      + statusCode);
>>          Objects.requireNonNull(headers);
>> -        Objects.requireNonNull(body);
>> +        Objects.requireNonNull(bodySupplier);
>>
>>          final var headersCopy = Headers.of(headers);
>> -        final var bytes = body.getBytes(StandardCharsets.UTF_8);
>>
>>          return exchange -> {
>>              try (exchange) {
>> -                exchange.getRequestBody().readAllBytes();
>> +
>> exchange.getRequestBody().transferTo(OutputStream.nullOutputStream());
>> // discard
>>                  exchange.getResponseHeaders().putAll(headersCopy);
>> -                if (exchange.getRequestMethod().equals("HEAD")) {
>> -
>> exchange.getResponseHeaders().set("Content-Length",
>> Integer.toString(bytes.length));
>> -                    exchange.sendResponseHeaders(statusCode, -1);
>> -                }
>> -                else if (bytes.length == 0) {
>> -                    exchange.sendResponseHeaders(statusCode, -1);
>> +                var body = bodySupplier.get();
>> +                if (body == null) {
>> +                    exchange.sendResponseHeaders(500, -1); //
>> Internal Server Error
>>                  } else {
>> -                    exchange.sendResponseHeaders(statusCode, bytes.length);
>> -                    exchange.getResponseBody().write(bytes);
>> +                    final var bytes = body.getBytes(StandardCharsets.UTF_8);
>> +                    if (exchange.getRequestMethod().equals("HEAD")) {
>> +
>> exchange.getResponseHeaders().set("Content-Length",
>> Integer.toString(bytes.length));
>> +                        exchange.sendResponseHeaders(statusCode, -1);
>> +                    } else if (bytes.length == 0) {
>> +                        exchange.sendResponseHeaders(statusCode, -1);
>> +                    } else {
>> +                        exchange.sendResponseHeaders(statusCode, bytes.length);
>> +                        exchange.getResponseBody().write(bytes);
>> +                    }
>>                  }
>>              }
>>          };
>> diff --git a/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>> b/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>> index 85d271e44fa..d64fa03740f 100644
>> --- a/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>> +++ b/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>> @@ -81,7 +81,7 @@ public void testNull() {
>>          final var headers = new Headers();
>>          final var body = "";
>>          assertThrows(NPE, () -> HttpHandlers.of(200, null, body));
>> -        assertThrows(NPE, () -> HttpHandlers.of(200, headers, null));
>> +        assertThrows(NPE, () -> HttpHandlers.of(200, headers, (String) null));
>>      }
>>
>>      @Test

From ethan at mccue.dev  Mon Apr 28 21:52:25 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 28 Apr 2025 17:52:25 -0400
Subject: New convenience HttpHandler
In-Reply-To: <CA+NR86iE-=gahaxnNYNKgKA49S1MFqo-bo6mPJbO_Vhudy1cQg@mail.gmail.com>
References: <CAChcVu=Swc_PM2w55jxw5s=NmancKa4ooiEuxyePTZ1g-8mUQA@mail.gmail.com>
 <CA+NR86jNCUGrups_YTbXbmKQpYfiChDZbP0hJbgzhDUQx1_h3g@mail.gmail.com>
 <CAChcVunDyYveSuKZQwGKdMPQiREMrCF+VUT+hw-GSGsm05PapQ@mail.gmail.com>
 <CA+NR86iE-=gahaxnNYNKgKA49S1MFqo-bo6mPJbO_Vhudy1cQg@mail.gmail.com>
Message-ID: <CA+NR86ikzNFaUjbAAm8pDpgWu=AFKMkgZRwiM=a1azhagUMO=Q@mail.gmail.com>

Sorry, forgot reply-all

On Mon, Apr 28, 2025 at 5:52?PM Ethan McCue <ethan at mccue.dev> wrote:

> Today you would need to do the following:
>
> exchange -> {
>     var body = "example".getBytes();
>     exchange.sendResponseHeaders(200, body.length);
>     try (var os = exchange.getResponseBody()) {
>         os.write(body);
>     }
> }
>
> I don't think you need to read the request body, but I might be wrong
> about that. If so, I have some thinking to do. (and FileServerHandler
> needs to be fixed)
>
> And if you weren't doing a static value, you'd want to do this.
>
> exchange -> {
>     var body = compute().getBytes();
>     exchange.sendResponseHeaders(200, body.length == 0 ? -1 : body.length);
>     try (var os = exchange.getResponseBody()) {
>         os.write(body);
>     }
> }
>
> Where the body.length == 0 ? -1 : body.length is for technical
> correctness in case the body is length zero.
>
> Essentially, I think something approximately like what I have here should
> be integrated. https://github.com/bowbahdoe/jdk-httpserver
>
> The reason I'm not pushing on it is:
>
> * The design has a ResponseLength.known(..) and ResponseLength.unknown() which
> handle that 0 ? -1 nonsense, but that only works with corresponding patterns
> * ResponseLength should be value class
> * The Body interface has a defaultContentType which scratches at the back
> of my brain - Could a Body imply additional headers? Is it worth having
> just for JsonBody.of(...);?
>
> But essentially, this is the meat of it.
>
> exchange -> HttpExchanges.sendResponse(exchange, 200, Body.of("example"));
>
> interface Body {
>     void writeTo(OutputStream outputStream) throws IOException;
>
>     default ResponseLength responseLength() {
>         return ResponseLength.unknown();
>     }
>
>     default Optional<String> defaultContentType() {
>         return Optional.empty();
>     }
>
>     // ...
> }
>
>     public static void sendResponse(
>             HttpExchange exchange, int rCode, Body body
>     ) throws IOException {
>         body.defaultContentType()
>                 .ifPresent(contentType ->
> exchange.getResponseHeaders().putIfAbsent(
>                         "Content-Type",
>                         List.of(contentType)
>                 ));
>
>         sendResponseHeaders(exchange, rCode, body.responseLength());
>         try (var os = exchange.getResponseBody()) {
>             body.writeTo(os);
>         }
>     }
>
> On Mon, Apr 28, 2025 at 5:36?PM Pavel Rappo <pavel.rappo at gmail.com> wrote:
>
>> You are right that a function would be more general than a supplier.
>> That crossed my mind too. However, here, with greater generality comes
>> less convenience. Like with your example, don't you need to read a
>> request body and then finally close the exchange? Perhaps that can be
>> solved with better documentation rather than one more convenience
>> method. Perhaps documentation could provide (a snippet of) a skeletal
>> implementation of a handler.
>>
>> Also, even the "static string" convenience handler is problematic: no
>> one sets the content type because it's unknown: the passed string can
>> be HTML, JSON, plain text or what have you. And no one sets the
>> character encoding because (AFAIK) it only comes with the content type
>> and not on its own.
>>
>> On Mon, Apr 28, 2025 at 8:53?PM Ethan McCue <ethan at mccue.dev> wrote:
>> >
>> > My first thought is that if you are computing the string maybe you'd
>> want to look at the request. Or set a header for content type.
>> >
>> > I'm not going to push hard until valhalla is at least in preview (+
>> we've already talked it to death) but a Body abstraction would probably
>> solve your use-case more robustly than yet another method there.
>> >
>> > exchange -> exchange.sendResponse(200, Body.of("example"));
>> >
>> > On Mon, Apr 28, 2025 at 5:28?AM Pavel Rappo <pavel.rappo at gmail.com>
>> wrote:
>> >>
>> >> I'm using HttpServer to implement an HTTP probe [^1] that provides
>> >> application state at the time of probing. I find that convenience
>> >> handlers provided by HttpHandlers are insufficient for my use case. I
>> >> also find that implementing a custom HttpHandler is tricky without the
>> >> help of documentation.
>> >>
>> >> Perhaps my use case is typical enough so that HttpHandlers could
>> >> provide a new convenience handler. That handler would send a
>> >> dynamically supplied string, rather than a static string. If you also
>> >> find it useful, I'd appreciate it if we could discuss it. Before I
>> >> create a JBS issue, please have a look at this crude patch to see if
>> >> it makes sense to you in principle. Thanks.
>> >>
>> >> [^1]:
>> https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
>> >>
>> >> diff --git
>> a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>> >>
>> b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>> >> index 03642033914..987de0ede5d 100644
>> >> ---
>> a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>> >> +++
>> b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>> >> @@ -25,9 +25,11 @@
>> >>
>> >>  package com.sun.net.httpserver;
>> >>
>> >> +import java.io.OutputStream;
>> >>  import java.nio.charset.StandardCharsets;
>> >>  import java.util.Objects;
>> >>  import java.util.function.Predicate;
>> >> +import java.util.function.Supplier;
>> >>
>> >>  /**
>> >>   * Implementations of {@link com.sun.net.httpserver.HttpHandler
>> HttpHandler}
>> >> @@ -140,28 +142,60 @@ public static HttpHandler
>> >> handleOrElse(Predicate<Request> handlerTest,
>> >>       * @throws NullPointerException     if headers or body are null
>> >>       */
>> >>      public static HttpHandler of(int statusCode, Headers headers,
>> >> String body) {
>> >> +        Objects.requireNonNull(body);
>> >> +        return of(statusCode, headers, () -> body);
>> >> +    }
>> >> +
>> >> +    /**
>> >> +     * Returns an {@code HttpHandler} that sends a response
>> >> comprising the given
>> >> +     * {@code statusCode}, {@code headers}, and {@code body}.
>> >> +     *
>> >> +     * <p> This method creates a handler that reads and discards the
>> request
>> >> +     * body before it sets the response state and sends the response.
>> >> +     *
>> >> +     * <p> {@code headers} are the effective headers of the response.
>> The
>> >> +     * response <i>body bytes</i> are a {@code UTF-8} encoded byte
>> sequence of
>> >> +     * a string, which is supplied by {@code bodySupplier}
>> >> immediately after the request body is read. The response headers
>> >> +     * {@linkplain HttpExchange#sendResponseHeaders(int, long) are
>> sent} with
>> >> +     * the given {@code statusCode} and the body bytes' length (or
>> {@code -1}
>> >> +     * if the body is empty). The body bytes are then sent as
>> response body,
>> >> +     * unless the body is empty, in which case no response body is
>> sent.
>> >> +     *
>> >> +     * @param statusCode a response status code
>> >> +     * @param headers a headers
>> >> +     * @param bodySupplier a supplier for the response body string
>> >> +     * @return a handler
>> >> +     * @throws IllegalArgumentException if statusCode is not a
>> positive 3-digit
>> >> +     *                                  integer, as per rfc2616,
>> section 6.1.1
>> >> +     * @throws NullPointerException     if headers or body are null
>> >> +     */
>> >> +    public static HttpHandler of(int statusCode, Headers headers,
>> >> Supplier<String> bodySupplier) {
>> >>          if (statusCode < 100 || statusCode > 999)
>> >>              throw new IllegalArgumentException("statusCode must be
>> 3-digit: "
>> >>                      + statusCode);
>> >>          Objects.requireNonNull(headers);
>> >> -        Objects.requireNonNull(body);
>> >> +        Objects.requireNonNull(bodySupplier);
>> >>
>> >>          final var headersCopy = Headers.of(headers);
>> >> -        final var bytes = body.getBytes(StandardCharsets.UTF_8);
>> >>
>> >>          return exchange -> {
>> >>              try (exchange) {
>> >> -                exchange.getRequestBody().readAllBytes();
>> >> +
>> >> exchange.getRequestBody().transferTo(OutputStream.nullOutputStream());
>> >> // discard
>> >>                  exchange.getResponseHeaders().putAll(headersCopy);
>> >> -                if (exchange.getRequestMethod().equals("HEAD")) {
>> >> -
>> >> exchange.getResponseHeaders().set("Content-Length",
>> >> Integer.toString(bytes.length));
>> >> -                    exchange.sendResponseHeaders(statusCode, -1);
>> >> -                }
>> >> -                else if (bytes.length == 0) {
>> >> -                    exchange.sendResponseHeaders(statusCode, -1);
>> >> +                var body = bodySupplier.get();
>> >> +                if (body == null) {
>> >> +                    exchange.sendResponseHeaders(500, -1); //
>> >> Internal Server Error
>> >>                  } else {
>> >> -                    exchange.sendResponseHeaders(statusCode,
>> bytes.length);
>> >> -                    exchange.getResponseBody().write(bytes);
>> >> +                    final var bytes =
>> body.getBytes(StandardCharsets.UTF_8);
>> >> +                    if (exchange.getRequestMethod().equals("HEAD")) {
>> >> +
>> >> exchange.getResponseHeaders().set("Content-Length",
>> >> Integer.toString(bytes.length));
>> >> +                        exchange.sendResponseHeaders(statusCode, -1);
>> >> +                    } else if (bytes.length == 0) {
>> >> +                        exchange.sendResponseHeaders(statusCode, -1);
>> >> +                    } else {
>> >> +                        exchange.sendResponseHeaders(statusCode,
>> bytes.length);
>> >> +                        exchange.getResponseBody().write(bytes);
>> >> +                    }
>> >>                  }
>> >>              }
>> >>          };
>> >> diff --git
>> a/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>> >> b/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>> >> index 85d271e44fa..d64fa03740f 100644
>> >> ---
>> a/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>> >> +++
>> b/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>> >> @@ -81,7 +81,7 @@ public void testNull() {
>> >>          final var headers = new Headers();
>> >>          final var body = "";
>> >>          assertThrows(NPE, () -> HttpHandlers.of(200, null, body));
>> >> -        assertThrows(NPE, () -> HttpHandlers.of(200, headers, null));
>> >> +        assertThrows(NPE, () -> HttpHandlers.of(200, headers,
>> (String) null));
>> >>      }
>> >>
>> >>      @Test
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250428/631f9e41/attachment-0001.htm>

From ethan at mccue.dev  Mon Apr 28 22:48:25 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 28 Apr 2025 18:48:25 -0400
Subject: New convenience HttpHandler
In-Reply-To: <CA+NR86ikzNFaUjbAAm8pDpgWu=AFKMkgZRwiM=a1azhagUMO=Q@mail.gmail.com>
References: <CAChcVu=Swc_PM2w55jxw5s=NmancKa4ooiEuxyePTZ1g-8mUQA@mail.gmail.com>
 <CA+NR86jNCUGrups_YTbXbmKQpYfiChDZbP0hJbgzhDUQx1_h3g@mail.gmail.com>
 <CAChcVunDyYveSuKZQwGKdMPQiREMrCF+VUT+hw-GSGsm05PapQ@mail.gmail.com>
 <CA+NR86iE-=gahaxnNYNKgKA49S1MFqo-bo6mPJbO_Vhudy1cQg@mail.gmail.com>
 <CA+NR86ikzNFaUjbAAm8pDpgWu=AFKMkgZRwiM=a1azhagUMO=Q@mail.gmail.com>
Message-ID: <CA+NR86hgXmYQ+M1AYbgbSpyhEGiAAxA2R-4OKPcJjZPN0RXn+A@mail.gmail.com>

nevermind - i see the file server does read and discard any incoming bodies.

On Mon, Apr 28, 2025 at 5:52?PM Ethan McCue <ethan at mccue.dev> wrote:

> Sorry, forgot reply-all
>
> On Mon, Apr 28, 2025 at 5:52?PM Ethan McCue <ethan at mccue.dev> wrote:
>
>> Today you would need to do the following:
>>
>> exchange -> {
>>     var body = "example".getBytes();
>>     exchange.sendResponseHeaders(200, body.length);
>>     try (var os = exchange.getResponseBody()) {
>>         os.write(body);
>>     }
>> }
>>
>> I don't think you need to read the request body, but I might be wrong
>> about that. If so, I have some thinking to do. (and FileServerHandler
>> needs to be fixed)
>>
>> And if you weren't doing a static value, you'd want to do this.
>>
>> exchange -> {
>>     var body = compute().getBytes();
>>     exchange.sendResponseHeaders(200, body.length == 0 ? -1 :
>> body.length);
>>     try (var os = exchange.getResponseBody()) {
>>         os.write(body);
>>     }
>> }
>>
>> Where the body.length == 0 ? -1 : body.length is for technical
>> correctness in case the body is length zero.
>>
>> Essentially, I think something approximately like what I have here should
>> be integrated. https://github.com/bowbahdoe/jdk-httpserver
>>
>> The reason I'm not pushing on it is:
>>
>> * The design has a ResponseLength.known(..) and ResponseLength.unknown() which
>> handle that 0 ? -1 nonsense, but that only works with corresponding patterns
>> * ResponseLength should be value class
>> * The Body interface has a defaultContentType which scratches at the
>> back of my brain - Could a Body imply additional headers? Is it worth
>> having just for JsonBody.of(...);?
>>
>> But essentially, this is the meat of it.
>>
>> exchange -> HttpExchanges.sendResponse(exchange, 200, Body.of("example"));
>>
>> interface Body {
>>     void writeTo(OutputStream outputStream) throws IOException;
>>
>>     default ResponseLength responseLength() {
>>         return ResponseLength.unknown();
>>     }
>>
>>     default Optional<String> defaultContentType() {
>>         return Optional.empty();
>>     }
>>
>>     // ...
>> }
>>
>>     public static void sendResponse(
>>             HttpExchange exchange, int rCode, Body body
>>     ) throws IOException {
>>         body.defaultContentType()
>>                 .ifPresent(contentType ->
>> exchange.getResponseHeaders().putIfAbsent(
>>                         "Content-Type",
>>                         List.of(contentType)
>>                 ));
>>
>>         sendResponseHeaders(exchange, rCode, body.responseLength());
>>         try (var os = exchange.getResponseBody()) {
>>             body.writeTo(os);
>>         }
>>     }
>>
>> On Mon, Apr 28, 2025 at 5:36?PM Pavel Rappo <pavel.rappo at gmail.com>
>> wrote:
>>
>>> You are right that a function would be more general than a supplier.
>>> That crossed my mind too. However, here, with greater generality comes
>>> less convenience. Like with your example, don't you need to read a
>>> request body and then finally close the exchange? Perhaps that can be
>>> solved with better documentation rather than one more convenience
>>> method. Perhaps documentation could provide (a snippet of) a skeletal
>>> implementation of a handler.
>>>
>>> Also, even the "static string" convenience handler is problematic: no
>>> one sets the content type because it's unknown: the passed string can
>>> be HTML, JSON, plain text or what have you. And no one sets the
>>> character encoding because (AFAIK) it only comes with the content type
>>> and not on its own.
>>>
>>> On Mon, Apr 28, 2025 at 8:53?PM Ethan McCue <ethan at mccue.dev> wrote:
>>> >
>>> > My first thought is that if you are computing the string maybe you'd
>>> want to look at the request. Or set a header for content type.
>>> >
>>> > I'm not going to push hard until valhalla is at least in preview (+
>>> we've already talked it to death) but a Body abstraction would probably
>>> solve your use-case more robustly than yet another method there.
>>> >
>>> > exchange -> exchange.sendResponse(200, Body.of("example"));
>>> >
>>> > On Mon, Apr 28, 2025 at 5:28?AM Pavel Rappo <pavel.rappo at gmail.com>
>>> wrote:
>>> >>
>>> >> I'm using HttpServer to implement an HTTP probe [^1] that provides
>>> >> application state at the time of probing. I find that convenience
>>> >> handlers provided by HttpHandlers are insufficient for my use case. I
>>> >> also find that implementing a custom HttpHandler is tricky without the
>>> >> help of documentation.
>>> >>
>>> >> Perhaps my use case is typical enough so that HttpHandlers could
>>> >> provide a new convenience handler. That handler would send a
>>> >> dynamically supplied string, rather than a static string. If you also
>>> >> find it useful, I'd appreciate it if we could discuss it. Before I
>>> >> create a JBS issue, please have a look at this crude patch to see if
>>> >> it makes sense to you in principle. Thanks.
>>> >>
>>> >> [^1]:
>>> https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
>>> >>
>>> >> diff --git
>>> a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>>> >>
>>> b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>>> >> index 03642033914..987de0ede5d 100644
>>> >> ---
>>> a/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>>> >> +++
>>> b/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java
>>> >> @@ -25,9 +25,11 @@
>>> >>
>>> >>  package com.sun.net.httpserver;
>>> >>
>>> >> +import java.io.OutputStream;
>>> >>  import java.nio.charset.StandardCharsets;
>>> >>  import java.util.Objects;
>>> >>  import java.util.function.Predicate;
>>> >> +import java.util.function.Supplier;
>>> >>
>>> >>  /**
>>> >>   * Implementations of {@link com.sun.net.httpserver.HttpHandler
>>> HttpHandler}
>>> >> @@ -140,28 +142,60 @@ public static HttpHandler
>>> >> handleOrElse(Predicate<Request> handlerTest,
>>> >>       * @throws NullPointerException     if headers or body are null
>>> >>       */
>>> >>      public static HttpHandler of(int statusCode, Headers headers,
>>> >> String body) {
>>> >> +        Objects.requireNonNull(body);
>>> >> +        return of(statusCode, headers, () -> body);
>>> >> +    }
>>> >> +
>>> >> +    /**
>>> >> +     * Returns an {@code HttpHandler} that sends a response
>>> >> comprising the given
>>> >> +     * {@code statusCode}, {@code headers}, and {@code body}.
>>> >> +     *
>>> >> +     * <p> This method creates a handler that reads and discards the
>>> request
>>> >> +     * body before it sets the response state and sends the response.
>>> >> +     *
>>> >> +     * <p> {@code headers} are the effective headers of the
>>> response. The
>>> >> +     * response <i>body bytes</i> are a {@code UTF-8} encoded byte
>>> sequence of
>>> >> +     * a string, which is supplied by {@code bodySupplier}
>>> >> immediately after the request body is read. The response headers
>>> >> +     * {@linkplain HttpExchange#sendResponseHeaders(int, long) are
>>> sent} with
>>> >> +     * the given {@code statusCode} and the body bytes' length (or
>>> {@code -1}
>>> >> +     * if the body is empty). The body bytes are then sent as
>>> response body,
>>> >> +     * unless the body is empty, in which case no response body is
>>> sent.
>>> >> +     *
>>> >> +     * @param statusCode a response status code
>>> >> +     * @param headers a headers
>>> >> +     * @param bodySupplier a supplier for the response body string
>>> >> +     * @return a handler
>>> >> +     * @throws IllegalArgumentException if statusCode is not a
>>> positive 3-digit
>>> >> +     *                                  integer, as per rfc2616,
>>> section 6.1.1
>>> >> +     * @throws NullPointerException     if headers or body are null
>>> >> +     */
>>> >> +    public static HttpHandler of(int statusCode, Headers headers,
>>> >> Supplier<String> bodySupplier) {
>>> >>          if (statusCode < 100 || statusCode > 999)
>>> >>              throw new IllegalArgumentException("statusCode must be
>>> 3-digit: "
>>> >>                      + statusCode);
>>> >>          Objects.requireNonNull(headers);
>>> >> -        Objects.requireNonNull(body);
>>> >> +        Objects.requireNonNull(bodySupplier);
>>> >>
>>> >>          final var headersCopy = Headers.of(headers);
>>> >> -        final var bytes = body.getBytes(StandardCharsets.UTF_8);
>>> >>
>>> >>          return exchange -> {
>>> >>              try (exchange) {
>>> >> -                exchange.getRequestBody().readAllBytes();
>>> >> +
>>> >> exchange.getRequestBody().transferTo(OutputStream.nullOutputStream());
>>> >> // discard
>>> >>                  exchange.getResponseHeaders().putAll(headersCopy);
>>> >> -                if (exchange.getRequestMethod().equals("HEAD")) {
>>> >> -
>>> >> exchange.getResponseHeaders().set("Content-Length",
>>> >> Integer.toString(bytes.length));
>>> >> -                    exchange.sendResponseHeaders(statusCode, -1);
>>> >> -                }
>>> >> -                else if (bytes.length == 0) {
>>> >> -                    exchange.sendResponseHeaders(statusCode, -1);
>>> >> +                var body = bodySupplier.get();
>>> >> +                if (body == null) {
>>> >> +                    exchange.sendResponseHeaders(500, -1); //
>>> >> Internal Server Error
>>> >>                  } else {
>>> >> -                    exchange.sendResponseHeaders(statusCode,
>>> bytes.length);
>>> >> -                    exchange.getResponseBody().write(bytes);
>>> >> +                    final var bytes =
>>> body.getBytes(StandardCharsets.UTF_8);
>>> >> +                    if (exchange.getRequestMethod().equals("HEAD")) {
>>> >> +
>>> >> exchange.getResponseHeaders().set("Content-Length",
>>> >> Integer.toString(bytes.length));
>>> >> +                        exchange.sendResponseHeaders(statusCode, -1);
>>> >> +                    } else if (bytes.length == 0) {
>>> >> +                        exchange.sendResponseHeaders(statusCode, -1);
>>> >> +                    } else {
>>> >> +                        exchange.sendResponseHeaders(statusCode,
>>> bytes.length);
>>> >> +                        exchange.getResponseBody().write(bytes);
>>> >> +                    }
>>> >>                  }
>>> >>              }
>>> >>          };
>>> >> diff --git
>>> a/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>>> >> b/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>>> >> index 85d271e44fa..d64fa03740f 100644
>>> >> ---
>>> a/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>>> >> +++
>>> b/test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
>>> >> @@ -81,7 +81,7 @@ public void testNull() {
>>> >>          final var headers = new Headers();
>>> >>          final var body = "";
>>> >>          assertThrows(NPE, () -> HttpHandlers.of(200, null, body));
>>> >> -        assertThrows(NPE, () -> HttpHandlers.of(200, headers, null));
>>> >> +        assertThrows(NPE, () -> HttpHandlers.of(200, headers,
>>> (String) null));
>>> >>      }
>>> >>
>>> >>      @Test
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250428/68b5b33b/attachment-0001.htm>

From djelinski at openjdk.org  Tue Apr 29 09:49:42 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 29 Apr 2025 09:49:42 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v5]
In-Reply-To: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
Message-ID: <q5aVt7SDFvSWNgzHNn4YpN6IYnb39gdgiAm1vKvtHkg=.45f80d7e-c849-4a0a-8a06-54b021821eea@github.com>

> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
> 
> This PR adds the following validation:
> - pseudo-headers defined for requests are rejected in responses and push streams
> - pseudo-headers defined for responses are rejected in push promises
> - connection headers are rejected in responses and push streams
> 
> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
> 
> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with five additional commits since the last revision:

 - Add test for malformed push promise headers
 - Fix orphaned header consumer
 - Make HeaderDecoder constructor take a context parameter
 - Require ValidatingHeadersConsumer.context != null
 - Move test summary next to test bug number

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24569/files
  - new: https://git.openjdk.org/jdk/pull/24569/files/4c7f30f4..085d6b5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=03-04

  Stats: 200 lines in 5 files changed: 192 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24569/head:pull/24569

PR: https://git.openjdk.org/jdk/pull/24569

From djelinski at openjdk.org  Tue Apr 29 10:00:59 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 29 Apr 2025 10:00:59 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v4]
In-Reply-To: <NlkVgCJETAlUjDezJMZftWMIQYDMh835RYP3b2x4pOc=.ae11a6f3-d17f-4335-92a2-a9bb2c44d455@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <qxpuO5Luok2GIOJK3J3ltC-BksqJG13rFKyWkSPSWUM=.89c6e06d-9273-409d-a747-83b22c113303@github.com>
 <NlkVgCJETAlUjDezJMZftWMIQYDMh835RYP3b2x4pOc=.ae11a6f3-d17f-4335-92a2-a9bb2c44d455@github.com>
Message-ID: <D0-QiV7aRLwjqi8m-S764e2IfPkp5YQxklVN7ngHAfs=.09c9b582-ffe4-4400-bf8f-42454550af34@github.com>

On Mon, 28 Apr 2025 14:03:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix whitespace
>>  - Use ProtocolException for malformed headers
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 988:
> 
>> 986:                     // connection-level HPACK decoding state
>> 987:                     if (orphanedConsumer == null || frame.getClass() != ContinuationFrame.class) {
>> 988:                         orphanedConsumer = new ValidatingHeadersConsumer(Context.RESPONSE);
> 
> Should the context be `Context.REQUEST` if `hf instanceof PushPromiseFrame`?

Good catch. Should be fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2065969415

From djelinski at openjdk.org  Tue Apr 29 10:01:00 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 29 Apr 2025 10:01:00 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v4]
In-Reply-To: <1TAycTK47_BToDvYym_3uBudSKDPa_KzZ3AUryIFMBk=.f4cf7f63-1066-46d6-b77b-ed0a8f3cafb2@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <qxpuO5Luok2GIOJK3J3ltC-BksqJG13rFKyWkSPSWUM=.89c6e06d-9273-409d-a747-83b22c113303@github.com>
 <1TAycTK47_BToDvYym_3uBudSKDPa_KzZ3AUryIFMBk=.f4cf7f63-1066-46d6-b77b-ed0a8f3cafb2@github.com>
Message-ID: <xb0wXSMRrA79S3FFcBHyoQpKUB38KfcbS8FXCqoSgyY=.76f6747a-12ae-4bb8-a184-d317518ed8b4@github.com>

On Mon, 28 Apr 2025 14:14:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix whitespace
>>  - Use ProtocolException for malformed headers
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/HeaderDecoder.java line 34:
> 
>> 32: 
>> 33:     public HeaderDecoder() {
>> 34:         super(Context.REQUEST);
> 
> It feels a bit odd that a header "decoder" is being used in the context of a request. I then looked at the references of this class and I see that the only place this gets used/instantiated is in the `PushPromiseDecoder` and it then makes sense why the context used here is `REQUEST`. 
> 
> Do you think it would be better if we changed this `HeaderDecoder` constructor to accept a `Context` param and then have `PushPromiseDecoder` pass it the `Context.REQUEST`? That way it's a bit more clear at the use site, in PushPromiseDecoder, why `Context.REQUEST` gets used.

Right. The HeaderDecoder class is only used as a base class for PushPromiseDecoder, and I'm considering removing one of them in the future. For now I added the `context` parameter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2065972267

From dfuchs at openjdk.org  Tue Apr 29 13:35:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Apr 2025 13:35:52 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v5]
In-Reply-To: <q5aVt7SDFvSWNgzHNn4YpN6IYnb39gdgiAm1vKvtHkg=.45f80d7e-c849-4a0a-8a06-54b021821eea@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <q5aVt7SDFvSWNgzHNn4YpN6IYnb39gdgiAm1vKvtHkg=.45f80d7e-c849-4a0a-8a06-54b021821eea@github.com>
Message-ID: <cpUqyOLnXE6kjgYiPBCqXTaykylTQvM_tzbU4Ky4pMw=.c2197dd6-d368-4834-9645-d7f981433077@github.com>

On Tue, 29 Apr 2025 09:49:42 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Add test for malformed push promise headers
>  - Fix orphaned header consumer
>  - Make HeaderDecoder constructor take a context parameter
>  - Require ValidatingHeadersConsumer.context != null
>  - Move test summary next to test bug number

test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java line 77:

> 75:     static final String MAIN_RESPONSE_BODY = "the main response body";
> 76: 
> 77:     Http2TestServer server;

Can we use HttpServerAdapters and HttpTestServer here please? It will make it easier to create an equivalent test for HTTP/3.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2066439563

From michaelm at openjdk.org  Tue Apr 29 14:05:44 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 29 Apr 2025 14:05:44 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v9]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <NzPP110MTYsjFvnxaZZvJWEwhTSlL-N73G6EQv0Atu8=.d9a84bc7-d0e9-4002-9ddd-cd36dce3568a@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - doc + copyright update
 - ... and 13 more: https://git.openjdk.org/jdk/compare/6a0c24f9...1a14f4bd

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=08
  Stats: 949 lines in 42 files changed: 716 ins; 101 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From djelinski at openjdk.org  Tue Apr 29 15:40:20 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 29 Apr 2025 15:40:20 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v6]
In-Reply-To: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
Message-ID: <dbBDVU477dsaIOJpjUk5u1jU8RIwhHL2Z3wyRDZdDCA=.57c6f569-2dc6-490f-8f02-85b39d06665d@github.com>

> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
> 
> This PR adds the following validation:
> - pseudo-headers defined for requests are rejected in responses and push streams
> - pseudo-headers defined for responses are rejected in push promises
> - connection headers are rejected in responses and push streams
> 
> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
> 
> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Migrate to HttpServerAdapters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24569/files
  - new: https://git.openjdk.org/jdk/pull/24569/files/085d6b5f..d5c5e857

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=04-05

  Stats: 11 lines in 1 file changed: 1 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24569/head:pull/24569

PR: https://git.openjdk.org/jdk/pull/24569

From djelinski at openjdk.org  Tue Apr 29 15:40:20 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 29 Apr 2025 15:40:20 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v5]
In-Reply-To: <cpUqyOLnXE6kjgYiPBCqXTaykylTQvM_tzbU4Ky4pMw=.c2197dd6-d368-4834-9645-d7f981433077@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <q5aVt7SDFvSWNgzHNn4YpN6IYnb39gdgiAm1vKvtHkg=.45f80d7e-c849-4a0a-8a06-54b021821eea@github.com>
 <cpUqyOLnXE6kjgYiPBCqXTaykylTQvM_tzbU4Ky4pMw=.c2197dd6-d368-4834-9645-d7f981433077@github.com>
Message-ID: <V67nhKn1oTbx0zrHoRl_9YxCC8fuIjxOPgaQt0TKo88=.29ad96ad-e006-4c55-b3d8-6a15f040529a@github.com>

On Tue, 29 Apr 2025 13:32:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Add test for malformed push promise headers
>>  - Fix orphaned header consumer
>>  - Make HeaderDecoder constructor take a context parameter
>>  - Require ValidatingHeadersConsumer.context != null
>>  - Move test summary next to test bug number
>
> test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java line 77:
> 
>> 75:     static final String MAIN_RESPONSE_BODY = "the main response body";
>> 76: 
>> 77:     Http2TestServer server;
> 
> Can we use HttpServerAdapters and HttpTestServer here please? It will make it easier to create an equivalent test for HTTP/3.

done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2066846339

From dfuchs at openjdk.org  Tue Apr 29 16:09:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Apr 2025 16:09:49 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v6]
In-Reply-To: <dbBDVU477dsaIOJpjUk5u1jU8RIwhHL2Z3wyRDZdDCA=.57c6f569-2dc6-490f-8f02-85b39d06665d@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <dbBDVU477dsaIOJpjUk5u1jU8RIwhHL2Z3wyRDZdDCA=.57c6f569-2dc6-490f-8f02-85b39d06665d@github.com>
Message-ID: <GbJXAiFOTMuQK1hhbH4CkJWrE0D7jowhDpnjvraGsLw=.c447ca76-b8f3-4099-9bbc-23867aa9a6a3@github.com>

On Tue, 29 Apr 2025 15:40:20 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Migrate to HttpServerAdapters

LGTM. Please double check that the test still pass after the changes :-)

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24569#pullrequestreview-2804248170

From mullan at openjdk.org  Tue Apr 29 18:54:48 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 18:54:48 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v2]
In-Reply-To: <vY4EPwbma2L152XinG4QKBSoLZAavCk0xv8xFx2jlJ8=.2a8e342f-7c76-42c8-944f-09a542f2315a@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <vY4EPwbma2L152XinG4QKBSoLZAavCk0xv8xFx2jlJ8=.2a8e342f-7c76-42c8-944f-09a542f2315a@github.com>
Message-ID: <1Hqmd2bhIEmM17y03jXhCJOGWCuPiBXNG1yvBMq8xh4=.5521be52-9fb1-41bd-9fb6-f5cd12c6cd5f@github.com>

On Thu, 24 Apr 2025 18:30:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Skip explicit KeyPair initialization and let the provider default set it

test/jdk/sun/security/tools/keytool/PrintSSL.java line 57:

> 55:                 + "-keystore keystore -storepass passphrase "
> 56:                 + "-keypass passphrase -keyalg rsa -keysize 1024 "
> 57:                 + "-sigalg MD5withRSA -alias rsa_alias -dname CN=Server");

I think it would be better to use the current weak algorithms (as the comment on line 53 notes) and set the server's keymanager to SunX509 as it seems the purpose of this test is to ensure `keytool -printcert -sslserver` can deal with weak algorithms in certs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2067150242

From mullan at openjdk.org  Tue Apr 29 20:01:50 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 20:01:50 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v2]
In-Reply-To: <vY4EPwbma2L152XinG4QKBSoLZAavCk0xv8xFx2jlJ8=.2a8e342f-7c76-42c8-944f-09a542f2315a@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <vY4EPwbma2L152XinG4QKBSoLZAavCk0xv8xFx2jlJ8=.2a8e342f-7c76-42c8-944f-09a542f2315a@github.com>
Message-ID: <9LYMLlIiNt0v4FqENELTnXGo2HwLJaeuyoGTEctT5q8=.c4e59bd0-061c-4ffa-89cb-eedfca4a5727@github.com>

On Thu, 24 Apr 2025 18:30:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Skip explicit KeyPair initialization and let the provider default set it

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 52:

> 50: 
> 51: public class SSLSocketParametersTest extends SSLContextTemplate implements
> 52:         Serializable {

As an aside, I can't see any reason this test needs to implement Serializable, as nothing in the test depends on it or tests it. I removed it locally and the test still passes. Consider removing it as a cleanup (but if you do, run it thru mach5 to be safe).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2067282326

From abarashev at openjdk.org  Tue Apr 29 21:02:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Apr 2025 21:02:49 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v2]
In-Reply-To: <1Hqmd2bhIEmM17y03jXhCJOGWCuPiBXNG1yvBMq8xh4=.5521be52-9fb1-41bd-9fb6-f5cd12c6cd5f@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <vY4EPwbma2L152XinG4QKBSoLZAavCk0xv8xFx2jlJ8=.2a8e342f-7c76-42c8-944f-09a542f2315a@github.com>
 <1Hqmd2bhIEmM17y03jXhCJOGWCuPiBXNG1yvBMq8xh4=.5521be52-9fb1-41bd-9fb6-f5cd12c6cd5f@github.com>
Message-ID: <ygYX4-059hzPqoTGHukHfpX8glV7bRWKF8zZW6aAd_k=.4c429654-9101-4e98-a586-a3880e3c95af@github.com>

On Tue, 29 Apr 2025 18:51:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Skip explicit KeyPair initialization and let the provider default set it
>
> test/jdk/sun/security/tools/keytool/PrintSSL.java line 57:
> 
>> 55:                 + "-keystore keystore -storepass passphrase "
>> 56:                 + "-keypass passphrase -keyalg rsa -keysize 1024 "
>> 57:                 + "-sigalg MD5withRSA -alias rsa_alias -dname CN=Server");
> 
> I think it would be better to use the current weak algorithms (as the comment on line 53 notes) and set the server's keymanager to SunX509 (with the `javax.net.ssl.keyStoreType` system prop) as it seems the purpose of this test is to ensure `keytool -printcert -sslserver` can deal with weak algorithms in certs.

Indeed, good catch!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2067424166

From abarashev at openjdk.org  Tue Apr 29 21:05:47 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Apr 2025 21:05:47 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v2]
In-Reply-To: <9LYMLlIiNt0v4FqENELTnXGo2HwLJaeuyoGTEctT5q8=.c4e59bd0-061c-4ffa-89cb-eedfca4a5727@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <vY4EPwbma2L152XinG4QKBSoLZAavCk0xv8xFx2jlJ8=.2a8e342f-7c76-42c8-944f-09a542f2315a@github.com>
 <9LYMLlIiNt0v4FqENELTnXGo2HwLJaeuyoGTEctT5q8=.c4e59bd0-061c-4ffa-89cb-eedfca4a5727@github.com>
Message-ID: <dmAv_VXe742dSAxv6sF31JMCngkK5FQPwTfsMAAgOwk=.34428270-98ff-4929-b92a-634aeb5d0b94@github.com>

On Tue, 29 Apr 2025 19:58:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Skip explicit KeyPair initialization and let the provider default set it
>
> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 52:
> 
>> 50: 
>> 51: public class SSLSocketParametersTest extends SSLContextTemplate implements
>> 52:         Serializable {
> 
> As an aside, I can't see any reason this test needs to implement Serializable, as nothing in the test depends on it or tests it. I removed it locally and the test still passes. Consider removing it as a cleanup (but if you do, run it thru mach5 to be safe).

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2067427345

From abarashev at openjdk.org  Tue Apr 29 21:51:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Apr 2025 21:51:00 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v3]
In-Reply-To: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
Message-ID: <hMObcXlxkilJzSnGhWoxPUnImLIylfJ_G_NBs8sWcrc=.12708a01-64a9-478b-a8a3-9f35b3727a7a@github.com>

> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
> 
> Compatibility considerations:
> 
> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
> 
> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
> 
> **SUNX509**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> Finished running test 'micro:java.security.SSLHandshake'
> 
> **PKIX**
> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
> Finished running test 'micro:java.security.SSLHandshake'

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24756/files
  - new: https://git.openjdk.org/jdk/pull/24756/files/e5e83514..2b0c5525

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24756&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24756&range=01-02

  Stats: 10 lines in 2 files changed: 6 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24756/head:pull/24756

PR: https://git.openjdk.org/jdk/pull/24756

From ascarpino at openjdk.org  Tue Apr 29 23:12:45 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 29 Apr 2025 23:12:45 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v3]
In-Reply-To: <hMObcXlxkilJzSnGhWoxPUnImLIylfJ_G_NBs8sWcrc=.12708a01-64a9-478b-a8a3-9f35b3727a7a@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <hMObcXlxkilJzSnGhWoxPUnImLIylfJ_G_NBs8sWcrc=.12708a01-64a9-478b-a8a3-9f35b3727a7a@github.com>
Message-ID: <FJoIKS9NvaFkbatFGuHGyyFVVHsEMtbG7PnAVnHSs8I=.4c38526d-c5d1-4ebb-b199-26e42027ecfe@github.com>

On Tue, 29 Apr 2025 21:51:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

> > The discussion of #17956 contains an extensive performance analyses.
> 
> TL;DR: PKCS12 decrypts the private key before every use. The performance hit comes from applying PBKDF2 to the key encryption password.
> 
> SunX509 caches the private keys during initialization. PKIX always reads them directly from the keystore.

Is this a reflection of the perf test and not something seen in the real world, or something that needs to be fixed before or soon after this PR is integrated?

There doesn't seem to be much concern about a 2x slowdown which I'm a bit surprised about.

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

PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2840432152

From djelinski at openjdk.org  Wed Apr 30 06:20:46 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 30 Apr 2025 06:20:46 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v3]
In-Reply-To: <hMObcXlxkilJzSnGhWoxPUnImLIylfJ_G_NBs8sWcrc=.12708a01-64a9-478b-a8a3-9f35b3727a7a@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <hMObcXlxkilJzSnGhWoxPUnImLIylfJ_G_NBs8sWcrc=.12708a01-64a9-478b-a8a3-9f35b3727a7a@github.com>
Message-ID: <Ku8Z5ZzahNwHLX2TXysAE8HBQPM5c9aDVeZ6dao4RVo=.a0f58a96-c877-465a-9c06-9e705e3c826e@github.com>

On Tue, 29 Apr 2025 21:51:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

This slowdown is seen in the real world. It is concerning, but not easily fixable.

I am not in the TLS server business at the moment, but the cases I used to work with [*] were perfectly well served by SunX509, so I guess some users will just keep using that. The fix for the PKIX+PKCS12 speed is not exactly easy. The options we explored were either incompatible with the existing implementation, or introduced subtle bugs in some corner cases.

[*] The servers I used to work with had either only one certificate, or one RSA and one EC certificate. We had to manually disable the TLS_RSA and TLS_ECDH ciphers, but these are disabled by default today. SunX509 serves that situation pretty well.

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

PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2840918307

From duke at openjdk.org  Wed Apr 30 07:34:48 2025
From: duke at openjdk.org (duke)
Date: Wed, 30 Apr 2025 07:34:48 GMT
Subject: RFR: 8355370: Include server name in HTTP test server thread names
 to improve diagnostics [v2]
In-Reply-To: <m9tOBilckjtfBU6v4-Osr_3GEnUUgw70bEoFRAdqjDQ=.95127309-8fd9-48e7-87df-c568431f0524@github.com>
References: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
 <m9tOBilckjtfBU6v4-Osr_3GEnUUgw70bEoFRAdqjDQ=.95127309-8fd9-48e7-87df-c568431f0524@github.com>
Message-ID: <IVOKRNUPE8ghCbioCc1IeXpjDpeYMrvfgykEVTLBes0=.14c73b91-e01e-494d-ac0f-369a34d21e35@github.com>

On Thu, 24 Apr 2025 07:24:36 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Incorporates the test server name while deriving the HTTP/2 test server (i.e., `jdk.httpclient.test.lib.http2.Http2TestServer`) thread names to improve diagnostics.
>> 
>> ### Making `HttpTestServer` implement `AutoCloseable`
>> 
>> I carried out this out-of-scope enhancement along with this PR, since this one-liner gives nice try-with-resources convenience while writing tests using HTTP test servers. Note that [this change is already implemented for the in-progress HTTP/3 work](/dfuch/jdk/blob/9c2da664d2875b7e7986831fd716d05b7a8306f4/test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java#L1119).
>> 
>> ### Improving HTTP/2 test server thread names
>> 
>> The HTTP/2 server thread names are improved by modifying the server default executor to include the HTTP/2 server name in its thread names. We deliberately did nothing for the HTTP/1.1 server (provided by the `jdk.httpserver` module). `ServerImpl`, the default HTTP/1.1 server implementation, has only one thread by default: the dispatcher and it is named `HTTP-Dispatcher`. Since factory methods in `com.sun.net.httpserver.Http[s]Server` don?t have the notion of a _name_, introducing a name would require a public API change.
>> Instead the calling code that creates the server can supply an Executor which creates threads with whatever name
>> is appropriate for the application/test.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix code typo
>  - Override `AutoCloseable::close` in `Http2TestServerImpl`

@vy 
Your change (at version ccc7b0f63e5f06a1a50adb6696637223dcae558d) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24822#issuecomment-2841070943

From vyazici at openjdk.org  Wed Apr 30 07:34:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Apr 2025 07:34:48 GMT
Subject: RFR: 8355370: Include server name in HTTP test server thread names
 to improve diagnostics [v2]
In-Reply-To: <4_GUO7uqJigmCZ_sn_qhpkIcbAu2b_7wCIrxMjrGH2U=.5bdf06ff-7d7c-4313-857c-b2c395f8926b@github.com>
References: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
 <m9tOBilckjtfBU6v4-Osr_3GEnUUgw70bEoFRAdqjDQ=.95127309-8fd9-48e7-87df-c568431f0524@github.com>
 <4_GUO7uqJigmCZ_sn_qhpkIcbAu2b_7wCIrxMjrGH2U=.5bdf06ff-7d7c-4313-857c-b2c395f8926b@github.com>
Message-ID: <ZzcKY7zYAjIEpi3V8-OUuAaBao01X3hq21K7vU-B0ls=.741b5415-76b3-4dc5-a061-a16e4fec80ce@github.com>

On Fri, 25 Apr 2025 12:46:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix code typo
>>  - Override `AutoCloseable::close` in `Http2TestServerImpl`
>
> This looks OK to me.

@jaikiran, @dfuch, thanks so much for the reviews. I will appreciate one more hand-holding by sponsoring the PR. :pleading_face:

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

PR Comment: https://git.openjdk.org/jdk/pull/24822#issuecomment-2841072448

From vyazici at openjdk.org  Wed Apr 30 08:17:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Apr 2025 08:17:53 GMT
Subject: Integrated: 8355370: Include server name in HTTP test server thread
 names to improve diagnostics
In-Reply-To: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
References: <euVhOPVS4fNWI-w5mBscg5eOpEBJaOPii7NEqxHPnTE=.b556e77c-d7b6-458c-9fa0-df2d98bce209@github.com>
Message-ID: <9IEt40MKQnRNJu04LMGjaOHI4FF0A_gRv9Hq1p8-Vr4=.8846eda3-715d-4a79-9ed4-f720644397de@github.com>

On Wed, 23 Apr 2025 10:18:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Incorporates the test server name while deriving the HTTP/2 test server (i.e., `jdk.httpclient.test.lib.http2.Http2TestServer`) thread names to improve diagnostics.
> 
> ### Making `HttpTestServer` implement `AutoCloseable`
> 
> I carried out this out-of-scope enhancement along with this PR, since this one-liner gives nice try-with-resources convenience while writing tests using HTTP test servers. Note that [this change is already implemented for the in-progress HTTP/3 work](/dfuch/jdk/blob/9c2da664d2875b7e7986831fd716d05b7a8306f4/test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java#L1119).
> 
> ### Improving HTTP/2 test server thread names
> 
> The HTTP/2 server thread names are improved by modifying the server default executor to include the HTTP/2 server name in its thread names. We deliberately did nothing for the HTTP/1.1 server (provided by the `jdk.httpserver` module). `ServerImpl`, the default HTTP/1.1 server implementation, has only one thread by default: the dispatcher and it is named `HTTP-Dispatcher`. Since factory methods in `com.sun.net.httpserver.Http[s]Server` don?t have the notion of a _name_, introducing a name would require a public API change.
> Instead the calling code that creates the server can supply an Executor which creates threads with whatever name
> is appropriate for the application/test.

This pull request has now been integrated.

Changeset: 7d9a4383
Author:    Volkan Yazici <vyazici at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d9a43839ad190a53efdbcc7afd1728760c14e21
Stats:     28 lines in 2 files changed: 13 ins; 6 del; 9 mod

8355370: Include server name in HTTP test server thread names to improve diagnostics

Reviewed-by: dfuchs, jpai

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

PR: https://git.openjdk.org/jdk/pull/24822

From jpai at openjdk.org  Wed Apr 30 08:30:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 08:30:47 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v6]
In-Reply-To: <dbBDVU477dsaIOJpjUk5u1jU8RIwhHL2Z3wyRDZdDCA=.57c6f569-2dc6-490f-8f02-85b39d06665d@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <dbBDVU477dsaIOJpjUk5u1jU8RIwhHL2Z3wyRDZdDCA=.57c6f569-2dc6-490f-8f02-85b39d06665d@github.com>
Message-ID: <SH84bQgG5NyAxZ4XN1txCZhneI6r1wYNTHTTGWhljB4=.0517c4c3-ae59-4341-9a2a-b91ae017caf2@github.com>

On Tue, 29 Apr 2025 15:40:20 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Migrate to HttpServerAdapters

test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java line 87:

> 85:         int port = server.getAddress().getPort();
> 86:         System.err.println("Server listening on port " + port);
> 87:         uri = new URI("http://localhost:" + port + "/foo/a/b/c");

Hello Daniel, I think we should avoid `localhost` usage here and instead use `URIBuilder` test library util and then pass it  `InetAddress.getLoopbackAddress()` as the host. That should help avoid issues related to `localhost` being mapped to some other address and at the same time allow constructing the right URL when `InetAddress.getLoopbackAddress()` returns an IPv6 address.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2068156334

From dfuchs at openjdk.org  Wed Apr 30 08:58:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Apr 2025 08:58:47 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v6]
In-Reply-To: <SH84bQgG5NyAxZ4XN1txCZhneI6r1wYNTHTTGWhljB4=.0517c4c3-ae59-4341-9a2a-b91ae017caf2@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <dbBDVU477dsaIOJpjUk5u1jU8RIwhHL2Z3wyRDZdDCA=.57c6f569-2dc6-490f-8f02-85b39d06665d@github.com>
 <SH84bQgG5NyAxZ4XN1txCZhneI6r1wYNTHTTGWhljB4=.0517c4c3-ae59-4341-9a2a-b91ae017caf2@github.com>
Message-ID: <cZD-GJNqSQS7JbjCZDxRdRdlejdBV68kWKv8Jp772_s=.11f6ed49-1b41-42fe-afa6-fde622c8b79f@github.com>

On Wed, 30 Apr 2025 08:28:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Migrate to HttpServerAdapters
>
> test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java line 87:
> 
>> 85:         int port = server.getAddress().getPort();
>> 86:         System.err.println("Server listening on port " + port);
>> 87:         uri = new URI("http://localhost:" + port + "/foo/a/b/c");
> 
> Hello Daniel, I think we should avoid `localhost` usage here and instead use `URIBuilder` test library util and then pass it  `InetAddress.getLoopbackAddress()` as the host. That should help avoid issues related to `localhost` being mapped to some other address and at the same time allow constructing the right URL when `InetAddress.getLoopbackAddress()` returns an IPv6 address.

Ah - good point - you can also simply use `new URI("http://" + server.serverAuthority() + "/foo/a/b/c")`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2068202514

From djelinski at openjdk.org  Wed Apr 30 09:30:05 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 30 Apr 2025 09:30:05 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v7]
In-Reply-To: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
Message-ID: <2zWw5KWn9o6RPrnaMD4L2hIC0FgnTPTs0klKAtU3SfU=.e5f077d1-d3ae-4766-9523-d5d8a1d8b4a1@github.com>

> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
> 
> This PR adds the following validation:
> - pseudo-headers defined for requests are rejected in responses and push streams
> - pseudo-headers defined for responses are rejected in push promises
> - connection headers are rejected in responses and push streams
> 
> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
> 
> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Remove localhost usage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24569/files
  - new: https://git.openjdk.org/jdk/pull/24569/files/d5c5e857..2192f15f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24569&range=05-06

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24569/head:pull/24569

PR: https://git.openjdk.org/jdk/pull/24569

From djelinski at openjdk.org  Wed Apr 30 09:30:05 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 30 Apr 2025 09:30:05 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v6]
In-Reply-To: <cZD-GJNqSQS7JbjCZDxRdRdlejdBV68kWKv8Jp772_s=.11f6ed49-1b41-42fe-afa6-fde622c8b79f@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <dbBDVU477dsaIOJpjUk5u1jU8RIwhHL2Z3wyRDZdDCA=.57c6f569-2dc6-490f-8f02-85b39d06665d@github.com>
 <SH84bQgG5NyAxZ4XN1txCZhneI6r1wYNTHTTGWhljB4=.0517c4c3-ae59-4341-9a2a-b91ae017caf2@github.com>
 <cZD-GJNqSQS7JbjCZDxRdRdlejdBV68kWKv8Jp772_s=.11f6ed49-1b41-42fe-afa6-fde622c8b79f@github.com>
Message-ID: <faAiqe6JhredPnQmIUGIdc4nBdmocGz6YHRJbDEl494=.6f5d52fe-a64b-4300-817f-8b9e90ac8f07@github.com>

On Wed, 30 Apr 2025 08:55:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/http2/BadPushPromiseTest.java line 87:
>> 
>>> 85:         int port = server.getAddress().getPort();
>>> 86:         System.err.println("Server listening on port " + port);
>>> 87:         uri = new URI("http://localhost:" + port + "/foo/a/b/c");
>> 
>> Hello Daniel, I think we should avoid `localhost` usage here and instead use `URIBuilder` test library util and then pass it  `InetAddress.getLoopbackAddress()` as the host. That should help avoid issues related to `localhost` being mapped to some other address and at the same time allow constructing the right URL when `InetAddress.getLoopbackAddress()` returns an IPv6 address.
>
> Ah - good point - you can also simply use `new URI("http://" + server.serverAuthority() + "/foo/a/b/c")`

Good catch! Switched to `serverAuthority()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24569#discussion_r2068267507

From jpai at openjdk.org  Wed Apr 30 09:41:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Apr 2025 09:41:52 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v7]
In-Reply-To: <2zWw5KWn9o6RPrnaMD4L2hIC0FgnTPTs0klKAtU3SfU=.e5f077d1-d3ae-4766-9523-d5d8a1d8b4a1@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <2zWw5KWn9o6RPrnaMD4L2hIC0FgnTPTs0klKAtU3SfU=.e5f077d1-d3ae-4766-9523-d5d8a1d8b4a1@github.com>
Message-ID: <67xvTRvLwRuJwzalwZxq_vNgo8-m5hIBYmtRDTCH5RA=.a399a2e2-a507-41a1-be6c-2a8428cae82f@github.com>

On Wed, 30 Apr 2025 09:30:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove localhost usage

Thank you Daniel for the updates. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24569#pullrequestreview-2806477643

From dfuchs at openjdk.org  Wed Apr 30 10:18:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Apr 2025 10:18:55 GMT
Subject: RFR: 8354276: Strict HTTP header validation [v7]
In-Reply-To: <2zWw5KWn9o6RPrnaMD4L2hIC0FgnTPTs0klKAtU3SfU=.e5f077d1-d3ae-4766-9523-d5d8a1d8b4a1@github.com>
References: <Mps6RKSI5HcRLrSXpMROczFL_EXizWdqWii2KT_8aNo=.1fc9fc0d-3fe2-4b33-9d92-7b22f61d9d7f@github.com>
 <2zWw5KWn9o6RPrnaMD4L2hIC0FgnTPTs0klKAtU3SfU=.e5f077d1-d3ae-4766-9523-d5d8a1d8b4a1@github.com>
Message-ID: <qTiPcmuo0yFdF_86c-B7bn4-lSP98mPli1vyH5p8Jzs=.983a2522-8fe6-4716-a4d9-4a161043f135@github.com>

On Wed, 30 Apr 2025 09:30:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> RFC 9113 HTTP/2 mandates certain validation for HTTP headers; the HttpClient don't fully implement the described requirements.
>> 
>> This PR adds the following validation:
>> - pseudo-headers defined for requests are rejected in responses and push streams
>> - pseudo-headers defined for responses are rejected in push promises
>> - connection headers are rejected in responses and push streams
>> 
>> Connection headers are still accepted in push promises; that's because some popular server implementations were found to echo the request headers in push promises, and when the original request was a HTTP/1 upgrade, the push promise could contain one or more headers that were prohibited in HTTP/2 but allowed in HTTP/1.
>> 
>> An existing test was adapted to verify the handling of response headers. The modified test passes with this the changes in this PR, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove localhost usage

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24569#pullrequestreview-2806574506

From dfuchs at openjdk.org  Wed Apr 30 10:19:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Apr 2025 10:19:54 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v3]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <c4i3BTXSuEUL2Uq4LqWROAtCAc442kFglBIGAb28V_U=.fbda2f82-2ddd-40dd-b7cd-757a8748915b@github.com>

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 411 commits:

 - merge latest changes from master branch
 - http3: jep review feedback: rename HttpRequest.HttpRequestOption into top-level HttpOption. Http3DiscoveryMode is now an inner class in HttpOption. Improved protocol selection documentation in HttpClient class-level apiNote. Add links from Builder.version methods.
 - merge latest changes from master branch
 - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
 - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
 - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
 - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
 - http3: minor improvement to log message
 - http3: Artur's review - remove commented out code from test
 - http3: Artur's review - make methods package private
 - ... and 401 more: https://git.openjdk.org/jdk/compare/c2485d5f...dfa26044

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=02
  Stats: 102863 lines in 472 files changed: 100230 ins; 1120 del; 1513 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

PR: https://git.openjdk.org/jdk/pull/24751

From dfuchs at openjdk.org  Wed Apr 30 14:47:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Apr 2025 14:47:58 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v3]
In-Reply-To: <c4i3BTXSuEUL2Uq4LqWROAtCAc442kFglBIGAb28V_U=.fbda2f82-2ddd-40dd-b7cd-757a8748915b@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <c4i3BTXSuEUL2Uq4LqWROAtCAc442kFglBIGAb28V_U=.fbda2f82-2ddd-40dd-b7cd-757a8748915b@github.com>
Message-ID: <6rOiDIAFxUmXy6EAQtxDeTbep9DOF5MJIKgi4fGTnQI=.a29afc53-d854-4d0a-9135-b454146b5a3c@github.com>

On Wed, 30 Apr 2025 10:19:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 411 commits:
> 
>  - merge latest changes from master branch
>  - http3: jep review feedback: rename HttpRequest.HttpRequestOption into top-level HttpOption. Http3DiscoveryMode is now an inner class in HttpOption. Improved protocol selection documentation in HttpClient class-level apiNote. Add links from Builder.version methods.
>  - merge latest changes from master branch
>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - ... and 401 more: https://git.openjdk.org/jdk/compare/c2485d5f...dfa26044

The PR has been updated with the following API doc changes:

 1. rename HttpRequestOption into HttpOption and make it
    a top level class.
    
 2. move Http3DiscoveryMode as an inner class in HttpOption

 3. improve the paragraph that talks about version selection
    in the HttpClient class-level impl note.

 4. improve the API documentation of the various Builder.version
    and HttpClient.version methods, adding links to the above
    paragraph

The CSR has not been updated yet - but an API documentation of the `java.net.http` module including these changes can be seen [here](https://cr.openjdk.org/~dfuchs/8291976/apidoc.02/api/java.net.http/module-summary.html)

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

PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-2842231948

From abarashev at openjdk.org  Wed Apr 30 16:46:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 30 Apr 2025 16:46:48 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v3]
In-Reply-To: <hMObcXlxkilJzSnGhWoxPUnImLIylfJ_G_NBs8sWcrc=.12708a01-64a9-478b-a8a3-9f35b3727a7a@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
 <hMObcXlxkilJzSnGhWoxPUnImLIylfJ_G_NBs8sWcrc=.12708a01-64a9-478b-a8a3-9f35b3727a7a@github.com>
Message-ID: <7LViYz-2xcd3Ix0etPy2I4ZuGwHZ3R6__QWRqMziVCE=.7741a4db-2db6-4fbf-b05e-42c92851340a@github.com>

On Tue, 29 Apr 2025 21:51:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

I have a few points for making the change:

1. On my laptop the handshake time increased from 1ms to 2ms. So while it's a x2 increase it's not going to be noticeable.
2. I'm not 100% sure, but from what I read at least the half of the TLS connections these days are of resume type, and the performance for those is unchanged. Here is a good article from CloudFlare on this topic: https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure. They set session ticket lifetime to 18h.
3. Unlike SunX509, PKIX KeyManager checks local certificate signature algorithms against local algorithm constraints and also against peer-supported algorithms supplied by the peer. So technically we are in violation of TLSv1.3 RFC when using SunX509 because we ignore peer-supported certificate signature schemes. Also we don't respect our own algorithm constraints in `java.security` for local certificates which is the behavior users may expect.

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

PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2842610353

From eirbjo at openjdk.org  Wed Apr 30 17:31:48 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 30 Apr 2025 17:31:48 GMT
Subject: RFR: 8353440: Disable FTP fallback for non-local file URLs by
 default [v10]
In-Reply-To: <pix9LZ4OTrpnMplaDSo-FEXRElFJueNHAFHdhHvEAps=.37c9ed43-1b35-47e9-b7e9-26503ce59e49@github.com>
References: <Q8IV9t0e7c6NjhfhPOBqYHVN7lkrdgK1VfXQxRwbsoA=.bb16338c-ba9e-4028-97c2-e9224ea83fd8@github.com>
 <alH_36iuDRDdDG3OvzXXbzQVlOMuh0zoH2Aqt9C6Z_8=.42317dbf-31ea-4ac8-b758-4a98f43737c3@github.com>
 <sqN4yVKK2WkcLBDVe-3n-q4KjHjl_Dl-pQVYvUrB33c=.294c801b-4781-4584-9bb2-3da764869079@github.com>
 <pix9LZ4OTrpnMplaDSo-FEXRElFJueNHAFHdhHvEAps=.37c9ed43-1b35-47e9-b7e9-26503ce59e49@github.com>
Message-ID: <kprOpCxZK6NoJv_PtJ2JPng7M6CjqAPPvDIiXPGGaZg=.4b58052e-8692-4d2c-a0b3-6e0f3e9d40c9@github.com>

On Mon, 28 Apr 2025 09:21:54 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> > > I have added a Release Note as a subtask in the JBS issue, this also needs a review.
> > 
> > 
> > Hi Eirik, I have updated the wording of the release note at https://bugs.openjdk.org/browse/JDK-8354658 ; @AlanBateman or @Michael-Mc-Mahon may need to review my changes.
> 
> I fixed a few typos. Otherwise, it looks good.

Thanks Michael for your updates to the release note.

The property specification includes a recommendation that the ftp:// scheme should be used directly instead of relying on the file: scheme for FTP support.


Should we add some wording to that effect in the release note as well, to notify users that code relying on this legacy feature to resolve files using FTP should use explicit ftp:// URLs instead?

Note that I?m away from keyboard so cannot update JBS myself.

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

PR Comment: https://git.openjdk.org/jdk/pull/24657#issuecomment-2842772110

From wetmore at openjdk.org  Wed Apr 30 22:45:23 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 30 Apr 2025 22:45:23 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material
Message-ID: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>

Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.

CSR is underway.

Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

Commit messages:
 - 8341346: Add support for exporting TLS Keying Material

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341346
  Stats: 917 lines in 7 files changed: 898 ins; 2 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

PR: https://git.openjdk.org/jdk/pull/24976

From wetmore at openjdk.org  Wed Apr 30 23:32:01 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 30 Apr 2025 23:32:01 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v2]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <xHg1GSjDNAtWWVjduXkDY95TTxYmkgwqgN8-gNOPJ7o=.c264d575-1ff3-48ba-a3d6-a1cc2f8ec454@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak API to be more KDF like in unextractable case.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/f5a403c4..e9745966

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=00-01

  Stats: 9 lines in 2 files changed: 4 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

PR: https://git.openjdk.org/jdk/pull/24976

From wetmore at openjdk.org  Wed Apr 30 23:38:03 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 30 Apr 2025 23:38:03 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3]
In-Reply-To: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
References: <AH3MGMPyGc8XQpWxcpakNmyElCM9f8DHMgvsauFHV9Q=.47fb631e-8852-47c3-b495-08e1537bdd1c@github.com>
Message-ID: <S1460VI11FMzLIdf3F-FwRbcgZaE04fV4AcAeluYEp4=.a53c8a8c-ae14-488f-9c9f-ab3cf755c5bb@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  Moved too fast

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/e9745966..a0332f8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=01-02

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

PR: https://git.openjdk.org/jdk/pull/24976