From duke at openjdk.java.net  Wed Mar  2 11:56:22 2022
From: duke at openjdk.java.net (zzambers)
Date: Wed, 2 Mar 2022 11:56:22 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
Message-ID: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>

Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.

[1] https://bugs.openjdk.java.net/browse/JDK-8208526
[2] https://bugs.openjdk.java.net/browse/JDK-8216326

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

Commit messages:
 - javax/net/ssl/SSLSocket: Fixed API Note in javadoc

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From duke at openjdk.java.net  Wed Mar  2 11:56:23 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Wed, 2 Mar 2022 11:56:23 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
Message-ID: <_gpOcV6YIojpPWSY8v-Mn5SEdc1UfcNnpuG7_3FfYkU=.5c46ccc4-b9b5-43c2-9e2d-6b92559bea00@github.com>

On Tue, 1 Mar 2022 17:09:57 GMT, zzambers <duke at openjdk.java.net> wrote:

> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326

@zzambers I've created a corresponding issue for you in the tracker, please rename your PR title to 8282529 and the system should automatically mark your PR as ready for review

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From duke at openjdk.java.net  Wed Mar  2 11:56:24 2022
From: duke at openjdk.java.net (zzambers)
Date: Wed, 2 Mar 2022 11:56:24 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To: <_gpOcV6YIojpPWSY8v-Mn5SEdc1UfcNnpuG7_3FfYkU=.5c46ccc4-b9b5-43c2-9e2d-6b92559bea00@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <_gpOcV6YIojpPWSY8v-Mn5SEdc1UfcNnpuG7_3FfYkU=.5c46ccc4-b9b5-43c2-9e2d-6b92559bea00@github.com>
Message-ID: <1dy03NNttstKhBtGII_CDhF3h4T0zls0dhTl2S9Wbq8=.63d2ff0b-85d0-4f9a-b6ec-4533e983014a@github.com>

On Wed, 2 Mar 2022 07:13:36 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

>> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
>> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
>
> @zzambers I've created a corresponding issue for you in the tracker, please rename your PR title to 8282529 and the system should automatically mark your PR as ready for review

@TheShermanTanker thank you

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From dfuchs at openjdk.java.net  Wed Mar  2 12:47:06 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 2 Mar 2022 12:47:06 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
 HttpTransaction, HttpCallback from open/test/jdk/ tests [v3]
In-Reply-To: <bqz1SH5Gx01ehDTz1wQSrG0J4DBgoJ41XRcDeT5SFIk=.18e8258f-d6e7-4e76-bc2e-49e2ebcb8e0d@github.com>
References: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
 <bqz1SH5Gx01ehDTz1wQSrG0J4DBgoJ41XRcDeT5SFIk=.18e8258f-d6e7-4e76-bc2e-49e2ebcb8e0d@github.com>
Message-ID: <3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>

On Fri, 25 Feb 2022 15:06:29 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

>> Updated following remaining tests to remove depenedies of TestHttpServer, HttpTransaction, HttpCallback
>> open/test/jdk/java/net/ProxySelector/LoopbackAddresses.java
>> open/test/jdk/java/net/ProxySelector/ProxyTest.java
>> open/test/jdk/java/net/URL/PerConnectionProxy.java
>> open/test/jdk/java/net/URLConnection/B5052093.java
>> open/test/jdk/sun/net/www/AuthHeaderTest.java
>> open/test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed extra whitespace

test/jdk/java/net/ProxySelector/LoopbackAddresses.java line 168:

> 166:         try(PrintWriter pw = new PrintWriter(exchange.getResponseBody())) {
> 167:             pw.print("Hello .");
> 168:         }

I know that now UTF-8 is supposed to be the default - but I'd prefer to either make it explicit, or add a comment stating that since Java 18 PrintWriter will use UTF-8 encoding by default.

test/jdk/java/net/ProxySelector/ProxyTest.java line 116:

> 114:             e.printStackTrace();
> 115:         }
> 116:         try(PrintWriter pw = new PrintWriter(exchange.getResponseBody())) {

Same remark here

test/jdk/java/net/URL/PerConnectionProxy.java line 234:

> 232:         } catch (IOException e) {
> 233:         }
> 234:         try(PrintWriter pw = new PrintWriter(exchange.getResponseBody())) {

And here too

test/jdk/java/net/URLConnection/B5052093.java line 113:

> 111:             exchange.close();
> 112:         } catch (IOException e) {
> 113:             e.printStackTrace();

Are you sure that this results in the same response headers than before?
If I'm not mistaken here we will send both Content-Length and Transfer-Encoding: chunked. Was that what the previous server did, and what the test wants to test?

test/jdk/sun/net/www/AuthHeaderTest.java line 139:

> 137:     void okReply (HttpExchange req) throws IOException {
> 138:         req.sendResponseHeaders (200, 0);
> 139:         try(PrintWriter pw = new PrintWriter(req.getResponseBody())) {

Same remark about UTF-8

test/jdk/sun/net/www/AuthHeaderTest.java line 167:

> 165:         }
> 166:     }
> 167: }

missing newline at end of file?

test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 157:

> 155: }
> 156: 
> 157: class SimpleHttpTransactionHandler implements HttpHandler

the boolean `failed` should at least be volatile

test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 178:

> 176:                     responseBody[i] = 0x41;
> 177:                 trans.sendResponseHeaders(200, 0);
> 178:                 try(PrintWriter pw = new PrintWriter(trans.getResponseBody())) {

Same remark about UTF-8 here again

test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 206:

> 204:                 // override the Content-length header to be greater than the actual response body
> 205:                 trans.getResponseHeaders().set("Content-length", Integer.toString(responseBody.length+1));
> 206:                 trans.sendResponseHeaders(200, 0);

Here again we will be mixing Content-Length and chunked

test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 207:

> 205:                 trans.getResponseHeaders().set("Content-length", Integer.toString(responseBody.length+1));
> 206:                 trans.sendResponseHeaders(200, 0);
> 207:                 try(PrintWriter pw = new PrintWriter(trans.getResponseBody())) {

Same remark for UTF-8

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

PR: https://git.openjdk.java.net/jdk/pull/7616

From xuelei at openjdk.java.net  Wed Mar  2 15:31:08 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 2 Mar 2022 15:31:08 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
Message-ID: <FsIYCzVeTBuQCJmaF2BCOPAqiy-CoKOSkTWFaHbZerE=.56573ed9-2745-4902-9f64-38f47eca11ac@github.com>

On Tue, 1 Mar 2022 17:09:57 GMT, zzambers <duke at openjdk.java.net> wrote:

> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326

Thank you for the nice catch.  The update looks good to me.  A CSR may be required for spec change.

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From wetmore at openjdk.java.net  Wed Mar  2 23:40:04 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 2 Mar 2022 23:40:04 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
Message-ID: <StYTvPkGWwzbfacwvgdw_qAO7WDShjZpnUFkDIlh1jE=.94f7497d-3593-4f9c-be23-c703795a700d@github.com>

On Tue, 1 Mar 2022 17:09:57 GMT, zzambers <duke at openjdk.java.net> wrote:

> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326

Please update the copyright to include 2022.  Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From wetmore at openjdk.java.net  Thu Mar  3 00:28:06 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 3 Mar 2022 00:28:06 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
Message-ID: <9rSTeWIbQhJoNbsw_h5Gf3_CkoPp1Mwu6lSFlNcJwik=.f37c22cc-55ef-4b54-b2e2-1c35aaa28642@github.com>

On Tue, 1 Mar 2022 17:09:57 GMT, zzambers <duke at openjdk.java.net> wrote:

> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326

Please also update JDK-8282529 to include the description (i.e. above).  IMHO, the bug should contain the information for the issue, rather than need to navigate 2 steps to the pull request.

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From jwaters at openjdk.java.net  Thu Mar  3 08:16:02 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Thu, 3 Mar 2022 08:16:02 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
In-Reply-To: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
Message-ID: <Y-LIvgZcy4RmzQ8Pem1Q_fKR6qQrJgaQ3Cl7zOctXzw=.ecad6beb-a73b-4a68-a6cb-970c0218cc1b@github.com>

On Tue, 1 Mar 2022 17:09:57 GMT, zzambers <duke at openjdk.java.net> wrote:

> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326

JDK-8282529 has been updated accordingly

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From duke at openjdk.java.net  Thu Mar  3 12:36:33 2022
From: duke at openjdk.java.net (zzambers)
Date: Thu, 3 Mar 2022 12:36:33 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v2]
In-Reply-To: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
Message-ID: <j4sqdo5vLlBwWSUNCpQEzns9tlaPY2ORgxEtJ7yhmfA=.d9a984be-82c6-4bfa-8632-56ced31828ab@github.com>

> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326

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

  Updated copyright for SSLSocket.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7648/files
  - new: https://git.openjdk.java.net/jdk/pull/7648/files/ff33d3f6..7fe494ab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From jpai at openjdk.java.net  Thu Mar  3 16:21:22 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 3 Mar 2022 16:21:22 GMT
Subject: RFR: 8282617:
 sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a
 lock while dealing with inCache field
Message-ID: <vuYABjn2JkRldKtKcFn8X4otQv5ob-DNJ3gVEe2uLLw=.dcb1c006-732c-4410-938d-9c25c94345d4@github.com>

Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282617? 

The `HttpClient` class uses a `inCache` (internal) field to keep track of whether a connection is in the keep-alive cache. This is a mutable field and when dealing with this field the `HttpClient` class uses a lock.

The `HttpsClient` class extends this `HttpClient` class. It additionally overrides the `putInKeepAliveCache()` method to use a Https specific way of populating the keep alive cache. While doing so it also reads and updates the `inCache` `protected` field from its super `HttpClient` class, but doesn't use a lock to do so. This can thus cause a race condition when the `inCache` field gets accessed concurrently, for example a separate thread calling the `HttpClient#isInKeepAliveCache()` method.

To fix this issue, the commit here uses the same lock/unlock construct used in the `HttpClient` super class.

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

Commit messages:
 - 8282617: sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a lock while dealing with inCache field

Changes: https://git.openjdk.java.net/jdk/pull/7680/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7680&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282617
  Stats: 13 lines in 1 file changed: 7 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7680.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7680/head:pull/7680

PR: https://git.openjdk.java.net/jdk/pull/7680

From dfuchs at openjdk.java.net  Thu Mar  3 16:29:58 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 3 Mar 2022 16:29:58 GMT
Subject: RFR: 8282617:
 sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a
 lock while dealing with inCache field
In-Reply-To: <vuYABjn2JkRldKtKcFn8X4otQv5ob-DNJ3gVEe2uLLw=.dcb1c006-732c-4410-938d-9c25c94345d4@github.com>
References: <vuYABjn2JkRldKtKcFn8X4otQv5ob-DNJ3gVEe2uLLw=.dcb1c006-732c-4410-938d-9c25c94345d4@github.com>
Message-ID: <xv1f7jDP07FLCD3MGFnXYX7IV9rjyHq0oAcrnTRlYZI=.4c185128-fe79-47e0-ad68-e72cdd0eff00@github.com>

On Thu, 3 Mar 2022 16:13:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282617? 
> 
> The `HttpClient` class uses a `inCache` (internal) field to keep track of whether a connection is in the keep-alive cache. This is a mutable field and when dealing with this field the `HttpClient` class uses a lock.
> 
> The `HttpsClient` class extends this `HttpClient` class. It additionally overrides the `putInKeepAliveCache()` method to use a Https specific way of populating the keep alive cache. While doing so it also reads and updates the `inCache` `protected` field from its super `HttpClient` class, but doesn't use a lock to do so. This can thus cause a race condition when the `inCache` field gets accessed concurrently, for example a separate thread calling the `HttpClient#isInKeepAliveCache()` method.
> 
> To fix this issue, the commit here uses the same lock/unlock construct used in the `HttpClient` super class.

LGTM!

Please run tier1 and tier2 tests before integrating

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7680

From duke at openjdk.java.net  Fri Mar  4 10:41:44 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 4 Mar 2022 10:41:44 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
 HttpTransaction, HttpCallback from open/test/jdk/ tests [v4]
In-Reply-To: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
References: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
Message-ID: <BiHRSz1MytIpMou6z8JzB0C4yHn5hAee2i6_vPxoK8I=.282cdca9-2229-4c42-9714-000b3fbae85d@github.com>

> Updated following remaining tests to remove depenedies of TestHttpServer, HttpTransaction, HttpCallback
> open/test/jdk/java/net/ProxySelector/LoopbackAddresses.java
> open/test/jdk/java/net/ProxySelector/ProxyTest.java
> open/test/jdk/java/net/URL/PerConnectionProxy.java
> open/test/jdk/java/net/URLConnection/B5052093.java
> open/test/jdk/sun/net/www/AuthHeaderTest.java
> open/test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented the review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7616/files
  - new: https://git.openjdk.java.net/jdk/pull/7616/files/d62ba21c..f2218025

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=02-03

  Stats: 27 lines in 6 files changed: 15 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7616/head:pull/7616

PR: https://git.openjdk.java.net/jdk/pull/7616

From duke at openjdk.java.net  Fri Mar  4 11:10:05 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 4 Mar 2022 11:10:05 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
 HttpTransaction, HttpCallback from open/test/jdk/ tests [v3]
In-Reply-To: <3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
References: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
 <bqz1SH5Gx01ehDTz1wQSrG0J4DBgoJ41XRcDeT5SFIk=.18e8258f-d6e7-4e76-bc2e-49e2ebcb8e0d@github.com>
 <3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
Message-ID: <m24Zq-kzOH0kwSzv46cKXZSkIACdk3ZszM2S5qfrs-Q=.a74cff65-a6a0-4816-a6eb-57bd41e3836b@github.com>

On Wed, 2 Mar 2022 12:35:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed extra whitespace
>
> test/jdk/java/net/URLConnection/B5052093.java line 113:
> 
>> 111:             exchange.close();
>> 112:         } catch (IOException e) {
>> 113:             e.printStackTrace();
> 
> Are you sure that this results in the same response headers than before?
> If I'm not mistaken here we will send both Content-Length and Transfer-Encoding: chunked. Was that what the previous server did, and what the test wants to test?

Yes, previously also, setting the content-length Integer.MAX_VALUE)) + 2, and was not sending any content. Here wanted to test, that URLConnection.getContentLength() does not throw NumberFormatException and return -1 if content-length is long value.
In case of HttpExchange.setResponseHeader(). If responseLength is -1, then content-length value is overridden to 0, if already set explicitly. Same is the case when responseLength is > 0. Only in the case when responseLength == 0, content-length value is not overriden if already set explicitly., thats why I am using chunked encoding and not writing any data.

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

PR: https://git.openjdk.java.net/jdk/pull/7616

From michaelm at openjdk.java.net  Fri Mar  4 11:12:25 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 11:12:25 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
Message-ID: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>

Hi,

Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.enabledDigestAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.

- Michael

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

Commit messages:
 - fix whitespace
 - update property name. add documentation
 - fixed one more test
 - fixed up existing tests using digest auth
 - Merge branch 'master' into md5
 - added userhash support plus test
 - fixed problem in copyright header
 - added test
 - Merge branch 'master' into md5
 - update
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b6c35ae4...f0fb72de

Changes: https://git.openjdk.java.net/jdk/pull/7688/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281561
  Stats: 302 lines in 11 files changed: 247 ins; 3 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7688.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7688/head:pull/7688

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Fri Mar  4 11:12:26 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 11:12:26 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <pPySXvDFvx5w1WOmPN7u7JRheLpbq_SMyOI186RTmJU=.069ed6bb-4a01-4091-a3d3-6a5d455904b1@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.enabledDigestAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

I have still to add the doc update describing the system property, which will come shortly. I may suggest a change of name to the system property to better reflect its exact meaning/purpose

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From duke at openjdk.java.net  Fri Mar  4 11:14:09 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 4 Mar 2022 11:14:09 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
 HttpTransaction, HttpCallback from open/test/jdk/ tests [v3]
In-Reply-To: <3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
References: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
 <bqz1SH5Gx01ehDTz1wQSrG0J4DBgoJ41XRcDeT5SFIk=.18e8258f-d6e7-4e76-bc2e-49e2ebcb8e0d@github.com>
 <3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
Message-ID: <0GTe0mbO8c67ePUSioRk-mGHF_jE9E01h-qp93Hsd0M=.0df07e40-2f10-4964-b933-303703bb032c@github.com>

On Wed, 2 Mar 2022 12:42:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed extra whitespace
>
> test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 206:
> 
>> 204:                 // override the Content-length header to be greater than the actual response body
>> 205:                 trans.getResponseHeaders().set("Content-length", Integer.toString(responseBody.length+1));
>> 206:                 trans.sendResponseHeaders(200, 0);
> 
> Here again we will be mixing Content-Length and chunked

In case of HttpExchange.setResponseHeader(). If responseLength is -1, then content-length value is overridden to 0, if already set explicitly. Same is the case when responseLength is > 0. Only in the case when responseLength == 0, content-length value is not overriden if already set explicitly., that's why I am using chunked encoding and writing the data less than the content length.

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

PR: https://git.openjdk.java.net/jdk/pull/7616

From dfuchs at openjdk.java.net  Fri Mar  4 11:25:02 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 11:25:02 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
 HttpTransaction, HttpCallback from open/test/jdk/ tests [v3]
In-Reply-To: <0GTe0mbO8c67ePUSioRk-mGHF_jE9E01h-qp93Hsd0M=.0df07e40-2f10-4964-b933-303703bb032c@github.com>
References: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
 <bqz1SH5Gx01ehDTz1wQSrG0J4DBgoJ41XRcDeT5SFIk=.18e8258f-d6e7-4e76-bc2e-49e2ebcb8e0d@github.com>
 <3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
 <0GTe0mbO8c67ePUSioRk-mGHF_jE9E01h-qp93Hsd0M=.0df07e40-2f10-4964-b933-303703bb032c@github.com>
Message-ID: <d3ICbOI-8wolPqfWD80fDfIV3PUJdrl_pzpErlnLxKc=.29dc083b-9031-4eef-a419-3b41c3bff6bf@github.com>

On Fri, 4 Mar 2022 11:10:40 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

>> test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 206:
>> 
>>> 204:                 // override the Content-length header to be greater than the actual response body
>>> 205:                 trans.getResponseHeaders().set("Content-length", Integer.toString(responseBody.length+1));
>>> 206:                 trans.sendResponseHeaders(200, 0);
>> 
>> Here again we will be mixing Content-Length and chunked
>
> In case of HttpExchange.setResponseHeader(). If responseLength is -1, then content-length value is overridden to 0, if already set explicitly. Same is the case when responseLength is > 0. Only in the case when responseLength == 0, content-length value is not overriden if already set explicitly., that's why I am using chunked encoding and writing the data less than the content length.

I understand why you do it - but the client will react differently if both Content-Length *and* chunk are specified, as opposed to when only Content-Length is specified. So I just want to make sure that we are testing the same thing than before. If we are not testing the same thing, then you might have to use a ServerSocket directly - rather than an HttpServer, to make sure we're sending back the same things than before.

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

PR: https://git.openjdk.java.net/jdk/pull/7616

From dfuchs at openjdk.java.net  Fri Mar  4 11:29:04 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 11:29:04 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <-3RM0t4QgpM7fYEYS3GYFlSuYTV_uqQ1h0GbLHkfLvY=.d6576161-aa37-4153-88ca-4580df607637@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

Should we instead have a property to disable algorithms, whose default value would contain "MD5" by default?

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Fri Mar  4 11:37:04 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 11:37:04 GMT
Subject: RFR: 8282617:
 sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a
 lock while dealing with inCache field
In-Reply-To: <vuYABjn2JkRldKtKcFn8X4otQv5ob-DNJ3gVEe2uLLw=.dcb1c006-732c-4410-938d-9c25c94345d4@github.com>
References: <vuYABjn2JkRldKtKcFn8X4otQv5ob-DNJ3gVEe2uLLw=.dcb1c006-732c-4410-938d-9c25c94345d4@github.com>
Message-ID: <JRXt5kJU_dquuECj53I4nEq0ArP1scDznOGmm7tTku4=.86f5b06e-8f83-4cf6-bf0b-f4bc8185622e@github.com>

On Thu, 3 Mar 2022 16:13:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282617? 
> 
> The `HttpClient` class uses a `inCache` (internal) field to keep track of whether a connection is in the keep-alive cache. This is a mutable field and when dealing with this field the `HttpClient` class uses a lock.
> 
> The `HttpsClient` class extends this `HttpClient` class. It additionally overrides the `putInKeepAliveCache()` method to use a Https specific way of populating the keep alive cache. While doing so it also reads and updates the `inCache` `protected` field from its super `HttpClient` class, but doesn't use a lock to do so. This can thus cause a race condition when the `inCache` field gets accessed concurrently, for example a separate thread calling the `HttpClient#isInKeepAliveCache()` method.
> 
> To fix this issue, the commit here uses the same lock/unlock construct used in the `HttpClient` super class.

LGTM

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

Marked as reviewed by michaelm (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7680

From michaelm at openjdk.java.net  Fri Mar  4 12:07:05 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 12:07:05 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <-3RM0t4QgpM7fYEYS3GYFlSuYTV_uqQ1h0GbLHkfLvY=.d6576161-aa37-4153-88ca-4580df607637@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <-3RM0t4QgpM7fYEYS3GYFlSuYTV_uqQ1h0GbLHkfLvY=.d6576161-aa37-4153-88ca-4580df607637@github.com>
Message-ID: <lfvBnJWtI4oI6gBKrttPnCBFiZfnErjwWJLhvtWx1JQ=.d7aa3afe-b212-47ac-af21-7b1776943bd6@github.com>

On Fri, 4 Mar 2022 11:25:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Should we instead have a property to disable algorithms, whose default value would contain "MD5" by default?

I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames="" 

I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Fri Mar  4 12:16:05 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 12:16:05 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <lfvBnJWtI4oI6gBKrttPnCBFiZfnErjwWJLhvtWx1JQ=.d7aa3afe-b212-47ac-af21-7b1776943bd6@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <-3RM0t4QgpM7fYEYS3GYFlSuYTV_uqQ1h0GbLHkfLvY=.d6576161-aa37-4153-88ca-4580df607637@github.com>
 <lfvBnJWtI4oI6gBKrttPnCBFiZfnErjwWJLhvtWx1JQ=.d7aa3afe-b212-47ac-af21-7b1776943bd6@github.com>
Message-ID: <NpJ0OXXldLHS-N9vqC6eNyOjFo2RwhbL2lumeaYUfwI=.e3cd8794-8097-48ab-9f04-8e2f0f21aee7@github.com>

On Fri, 4 Mar 2022 12:03:44 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
> 
> I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.

Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Fri Mar  4 12:25:05 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 12:25:05 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <NpJ0OXXldLHS-N9vqC6eNyOjFo2RwhbL2lumeaYUfwI=.e3cd8794-8097-48ab-9f04-8e2f0f21aee7@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <-3RM0t4QgpM7fYEYS3GYFlSuYTV_uqQ1h0GbLHkfLvY=.d6576161-aa37-4153-88ca-4580df607637@github.com>
 <lfvBnJWtI4oI6gBKrttPnCBFiZfnErjwWJLhvtWx1JQ=.d7aa3afe-b212-47ac-af21-7b1776943bd6@github.com>
 <NpJ0OXXldLHS-N9vqC6eNyOjFo2RwhbL2lumeaYUfwI=.e3cd8794-8097-48ab-9f04-8e2f0f21aee7@github.com>
Message-ID: <oUufUbHwJLRcik5TPwq0iitrrpUAvlrubtkDyVisrdI=.e1d6c97b-69ee-4c70-a399-81f3ead1c1cb@github.com>

On Fri, 4 Mar 2022 12:12:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
> > I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
> 
> Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property

In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.

So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From duke at openjdk.java.net  Fri Mar  4 12:28:41 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 4 Mar 2022 12:28:41 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
 HttpTransaction, HttpCallback from open/test/jdk/ tests [v5]
In-Reply-To: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
References: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
Message-ID: <XgeD9yoyADCts8svvhT6tr6k3vBEVCTejnE15ypw8qg=.45e3eff7-5cf2-4f4d-923a-112e5d7c4357@github.com>

> Updated following remaining tests to remove depenedies of TestHttpServer, HttpTransaction, HttpCallback
> open/test/jdk/java/net/ProxySelector/LoopbackAddresses.java
> open/test/jdk/java/net/ProxySelector/ProxyTest.java
> open/test/jdk/java/net/URL/PerConnectionProxy.java
> open/test/jdk/java/net/URLConnection/B5052093.java
> open/test/jdk/sun/net/www/AuthHeaderTest.java
> open/test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java

Mahendra Chhipa 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 11 additional commits since the last revision:

 - Removed extra space.
 - Removed Transfer encoding chunked from B5045306
 - Merge branch 'master' into JDK-8282354
 - Implemented the review comments.
 - Removed extra whitespace
 - Implemented the review comments.
 - JDK-8282354 : Remove dependancy of TestHttpServer, HttpTransaction, HttpCallback from open/test/jdk/ tests
 - Merge branch 'master' into JDK-8282354
 - WIP
 - Merge branch 'master' into httptrans
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b46ce84b...7f947718

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7616/files
  - new: https://git.openjdk.java.net/jdk/pull/7616/files/f2218025..7f947718

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=03-04

  Stats: 18347 lines in 450 files changed: 12637 ins; 3117 del; 2593 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7616/head:pull/7616

PR: https://git.openjdk.java.net/jdk/pull/7616

From michaelm at openjdk.java.net  Fri Mar  4 12:33:06 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 12:33:06 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <yqvrz-W3cux_hmaHECFJjG6knx2QzmrILiFU6K3PMUY=.57c2e36a-51c8-45fc-a2b0-88e317187ecc@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

> > > I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
> > > I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
> > 
> > 
> > Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
> 
> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
> 
> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.



> > > I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
> > > I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
> > 
> > 
> > Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
> 
> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
> 
> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.

Thinking about it again, I wonder if we should just deprecate SHA-1 at the same time. I think there will be less compatibility impact than with MD5, and it's basically broken as well. I don't see a reason to opt out of other algorithms at this time.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From duke at openjdk.java.net  Fri Mar  4 12:57:03 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 4 Mar 2022 12:57:03 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
 HttpTransaction, HttpCallback from open/test/jdk/ tests [v3]
In-Reply-To: <d3ICbOI-8wolPqfWD80fDfIV3PUJdrl_pzpErlnLxKc=.29dc083b-9031-4eef-a419-3b41c3bff6bf@github.com>
References: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
 <bqz1SH5Gx01ehDTz1wQSrG0J4DBgoJ41XRcDeT5SFIk=.18e8258f-d6e7-4e76-bc2e-49e2ebcb8e0d@github.com>
 <3CBOcwFWAwk9Jwc7EnwDOgG88uYxIJ_p1vF35fEhEEw=.aae95663-905c-45ac-832f-d497d7409abc@github.com>
 <0GTe0mbO8c67ePUSioRk-mGHF_jE9E01h-qp93Hsd0M=.0df07e40-2f10-4964-b933-303703bb032c@github.com>
 <d3ICbOI-8wolPqfWD80fDfIV3PUJdrl_pzpErlnLxKc=.29dc083b-9031-4eef-a419-3b41c3bff6bf@github.com>
Message-ID: <KZElx0e4kftjkrls2C9W2456M3mcMOKxOMIPNjZyYDc=.176d211c-9f4b-4c86-a7b2-1e1c827eabff@github.com>

On Fri, 4 Mar 2022 11:21:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> In case of HttpExchange.setResponseHeader(). If responseLength is -1, then content-length value is overridden to 0, if already set explicitly. Same is the case when responseLength is > 0. Only in the case when responseLength == 0, content-length value is not overriden if already set explicitly., that's why I am using chunked encoding and writing the data less than the content length.
>
> I understand why you do it - but the client will react differently if both Content-Length *and* chunk are specified, as opposed to when only Content-Length is specified. So I just want to make sure that we are testing the same thing than before. If we are not testing the same thing, then you might have to use a ServerSocket directly - rather than an HttpServer, to make sure we're sending back the same things than before.

Now not using Transfer-Encoding Chunk.

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

PR: https://git.openjdk.java.net/jdk/pull/7616

From dfuchs at openjdk.java.net  Fri Mar  4 13:09:08 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 13:09:08 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <yqvrz-W3cux_hmaHECFJjG6knx2QzmrILiFU6K3PMUY=.57c2e36a-51c8-45fc-a2b0-88e317187ecc@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <yqvrz-W3cux_hmaHECFJjG6knx2QzmrILiFU6K3PMUY=.57c2e36a-51c8-45fc-a2b0-88e317187ecc@github.com>
Message-ID: <H3nbyCXMdWBVLF1kv9ppqU_g4x3PP3ZrN7GaHbSzRS8=.831a22e3-42ff-4b51-9814-5de507a76762@github.com>

On Fri, 4 Mar 2022 12:29:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> > So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
> 
> Thinking about it again, I wonder if we should just deprecate SHA-1 at the same time. I think there will be less compatibility impact than with MD5, and it's basically broken as well. I don't see a reason to opt out of other algorithms at this time.

I see - maybe we should have a security property identifying the list of algorithm that are disabled, and then a system property to reenable them?

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Fri Mar  4 13:24:04 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 13:24:04 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <Hm062gURZjxPb0xwXabJdsEOBjvvHNXiryuvGFAgdFs=.96ca460f-21f2-44f8-8bc4-189231f95c96@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 71:

> 69:     // This will probably be expanded to include SHA-1 eventually
> 70:     private static final Set<String> defDisabledAlgs =
> 71:         Set.of("MD5");

What I'm suggesting is that the content of this set could be seeded with the value of a Security Property, defined in java.security - rather than have the default value hardcoded here.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Fri Mar  4 13:41:04 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 13:41:04 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <Hm062gURZjxPb0xwXabJdsEOBjvvHNXiryuvGFAgdFs=.96ca460f-21f2-44f8-8bc4-189231f95c96@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Hm062gURZjxPb0xwXabJdsEOBjvvHNXiryuvGFAgdFs=.96ca460f-21f2-44f8-8bc4-189231f95c96@github.com>
Message-ID: <aEnwSBKYcC8YheRsPWFSTQOgIXiZ9WMccDvniYzn0TY=.62a243b9-386c-4b53-960b-4bd9d24084ad@github.com>

On Fri, 4 Mar 2022 13:13:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 71:
> 
>> 69:     // This will probably be expanded to include SHA-1 eventually
>> 70:     private static final Set<String> defDisabledAlgs =
>> 71:         Set.of("MD5");
> 
> What I'm suggesting is that the content of this set could be seeded with the value of a Security Property, defined in java.security - rather than have the default value hardcoded here.

Yes, I think that should work

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From jpai at openjdk.java.net  Fri Mar  4 13:54:03 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 13:54:03 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <77w1_8yIYvMSLVO-m-jwCpuT9wpI1aFjt9tw8TRb1Jc=.d23ace14-4993-4720-93fd-e12aeff52243@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

src/java.base/share/classes/java/net/doc-files/net-properties.html line 227:

> 225: 	      name.</P>
> 226: 	</OL>
> 227: 	<LI><P><B>{@systemProperty http.auth.digest.reEnabledAlgs}</B> (default: &lt;none&gt;)<BR>

Hello Michael, from what I understand of `doc-files` directory (which is where this html file resides) the `javadoc` tool considers it an unprocessed files location[1]. So would adding the `systemProperty` javadoc taglet here be necessary? I think this won't end up being listed in the system properties index generated by the javadoc tool and I think this line here will just get rendered literally.

[1] https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From ecki at zusammenkunft.net  Fri Mar  4 14:03:53 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 4 Mar 2022 14:03:53 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <yqvrz-W3cux_hmaHECFJjG6knx2QzmrILiFU6K3PMUY=.57c2e36a-51c8-45fc-a2b0-88e317187ecc@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <yqvrz-W3cux_hmaHECFJjG6knx2QzmrILiFU6K3PMUY=.57c2e36a-51c8-45fc-a2b0-88e317187ecc@github.com>
Message-ID: <AM9P193MB1142498D78B514FEDE420821FF059@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Hello,

While I like the idea of the user having to explicitely specify the rexenabled legacy algorithms (as opposed to removing the defaultsdisabled) it is not the style the other algorithm policies in JCE work - so it might be confusing.

But, more critically I would separate the enabling/implementing of new algorithms from disabling old ones. Especially since there needs to be changes on the server side first. (And I wonder if this can be negotiated anyway?).

So why not start with a ?provide new DIGEST Mechanisms? change? Having said that, would it need to start out with disabled new mechanisms so the update won?t change the behavior? (If there is no negotiation?)

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: net-dev <net-dev-retn at openjdk.java.net> im Auftrag von Michael McMahon <michaelm at openjdk.java.net>
Gesendet: Friday, March 4, 2022 1:33:06 PM
An: net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>
> - Michael

> > > I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
> > > I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
> >
> >
> > Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
>
> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
>
> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.



> > > I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
> > > I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
> >
> >
> > Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
>
> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
>
> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.

Thinking about it again, I wonder if we should just deprecate SHA-1 at the same time. I think there will be less compatibility impact than with MD5, and it's basically broken as well. I don't see a reason to opt out of other algorithms at this time.

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

PR: https://git.openjdk.java.net/jdk/pull/7688
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20220304/0dd0e778/attachment.htm>

From jpai at openjdk.java.net  Fri Mar  4 14:06:06 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 14:06:06 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <l_v1VPowuow2MEZ39flAUarQF13l79SOUnigsz8zLq8=.e31279fe-acbd-4ea2-8bb9-99f6f1e5ad14@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 524:

> 522:                 logger.info(msg + " This constraint may be relaxed by setting " +
> 523:                      "the \"http.auth.digest.enabledDigestAlgs\" system property.");
> 524:             }

I suspect this is a typo and perhaps should have been `http.auth.digest.reEnabledAlgs`?

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Fri Mar  4 14:09:07 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 4 Mar 2022 14:09:07 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <77w1_8yIYvMSLVO-m-jwCpuT9wpI1aFjt9tw8TRb1Jc=.d23ace14-4993-4720-93fd-e12aeff52243@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <77w1_8yIYvMSLVO-m-jwCpuT9wpI1aFjt9tw8TRb1Jc=.d23ace14-4993-4720-93fd-e12aeff52243@github.com>
Message-ID: <1IGxBt9tVPyAgq03cWyY6ME2yuZOHJYpej3A1rhp_lg=.2cbeadb1-831c-4e02-a5b8-ecf4ba1b54ce@github.com>

On Fri, 4 Mar 2022 13:50:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> src/java.base/share/classes/java/net/doc-files/net-properties.html line 227:
> 
>> 225: 	      name.</P>
>> 226: 	</OL>
>> 227: 	<LI><P><B>{@systemProperty http.auth.digest.reEnabledAlgs}</B> (default: &lt;none&gt;)<BR>
> 
> Hello Michael, from what I understand of `doc-files` directory (which is where this html file resides) the `javadoc` tool considers it an unprocessed files location[1]. So would adding the `systemProperty` javadoc taglet here be necessary? I think this won't end up being listed in the system properties index generated by the javadoc tool and I think this line here will just get rendered literally.
> 
> [1] https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html

This actually seems to work. If you build the docs for JDK mainline, you can search for instance, for `http.keepAlive.time.proxy` in the javadoc search box and it will lead you `net-properties.html`.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From jpai at openjdk.java.net  Fri Mar  4 14:15:06 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 14:15:06 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <EAqd667BDpn7-Qw0g9BIKDQVlIx9oDnfmc34XYQ0gvo=.8c5a959c-3fb2-4746-b780-f60cc2551108@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 443:

> 441:         } catch (IOException e) {
> 442:             // should not happen since the algorithm has already been
> 443:             // validated

Hello Michael, was this comment meant for something else? The comment feels a bit odd since it says "has already been validated" which isn't the case since the `validateAlgorithm` itself has failed here.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From jpai at openjdk.java.net  Fri Mar  4 14:23:06 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 14:23:06 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <_-1iD7d6NkfogWVFCWeBYH6H6VmuqXgM7tjGsVN0Nt0=.7a2d558b-ab63-4af5-b9bc-ed0cd794326c@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 584:

> 582:         boolean truncate256 = false;
> 583: 
> 584:         if (algorithm.equals("SHA-512-256")) {

It appears that the incoming param `algorithm`  can be of any case. In some other places like the `validateAlgorithm`, this `algorithm` value has been first converted to an uppercase value and then used for additional checks. Should a similar upper case conversion be done here before this equality check? Perhaps, we should convert this to upper case once and then pass it around to these `validateAlgorithm` and `computeUserhash` methods?

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From jpai at openjdk.java.net  Fri Mar  4 14:42:59 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 14:42:59 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <j66511JYJ8Zhid3D89lL6Ci1rp-t4upIhljydnY1Hd0=.156fc3d7-ab9b-41dc-beff-351be0ca85b0@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 423:

> 421:         String algorithm = params.getAlgorithm ();
> 422:         boolean userhash = params.getUserhash ();
> 423:         params.incrementNC ();

I am not familiar with the code and the request/response flow involved in this code, so what I mention may not be relevant. However, do you think the algorithm validation that we added in this PR should happen before this `incrementNC()` is called and the `ncString`  construction is done? I see that this incremented `ncCount` then gets used in the `checkResponse` part. In the case where the algorithm validation fails and we return `null` from this method (which effectively means not setting the authorization header), do you think the subsequent `checkResponse` would run into issues due to the `incrementNC()` being done here?

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Fri Mar  4 14:49:05 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 14:49:05 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <EAqd667BDpn7-Qw0g9BIKDQVlIx9oDnfmc34XYQ0gvo=.8c5a959c-3fb2-4746-b780-f60cc2551108@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <EAqd667BDpn7-Qw0g9BIKDQVlIx9oDnfmc34XYQ0gvo=.8c5a959c-3fb2-4746-b780-f60cc2551108@github.com>
Message-ID: <hHDLahtI1oUEcMBIMK-MQMXX8WL9kUVOaekZBNs08ag=.f3e890ae-99c0-4093-87d4-3441f58183e7@github.com>

On Fri, 4 Mar 2022 14:11:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 443:
> 
>> 441:         } catch (IOException e) {
>> 442:             // should not happen since the algorithm has already been
>> 443:             // validated
> 
> Hello Michael, was this comment meant for something else? The comment feels a bit odd since it says "has already been validated" which isn't the case since the `validateAlgorithm` itself has failed here.

Yes, copy and paste error. Thanks

> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 524:
> 
>> 522:                 logger.info(msg + " This constraint may be relaxed by setting " +
>> 523:                      "the \"http.auth.digest.enabledDigestAlgs\" system property.");
>> 524:             }
> 
> I suspect this is a typo and perhaps should have been `http.auth.digest.reEnabledAlgs`?

Thanks. I'm going to change the name once more and will update it then.

> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 584:
> 
>> 582:         boolean truncate256 = false;
>> 583: 
>> 584:         if (algorithm.equals("SHA-512-256")) {
> 
> It appears that the incoming param `algorithm`  can be of any case. In some other places like the `validateAlgorithm`, this `algorithm` value has been first converted to an uppercase value and then used for additional checks. Should a similar upper case conversion be done here before this equality check? Perhaps, we should convert this to upper case once and then pass it around to these `validateAlgorithm` and `computeUserhash` methods?

Right. I'll check all that for the next round.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From ccleary at openjdk.java.net  Fri Mar  4 14:52:32 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 4 Mar 2022 14:52:32 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large
Message-ID: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>

**Problem**
When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:


java.io.IOException: no statuscode in response
at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
...

This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.

**Fix**
To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.

- The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
- When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
- In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.

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

Commit messages:
 - 8263031: Created new flow for Push Promises followed by Continuations
 - 8263031: Setting END_HEADERS flag where appropriate
 - 8263031: Update test name and cleanup
 - 8263031: HttpClient throws Exception if it receives a Push Promise that is too large

Changes: https://git.openjdk.java.net/jdk/pull/7696/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263031
  Stats: 423 lines in 4 files changed: 336 ins; 67 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7696.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7696/head:pull/7696

PR: https://git.openjdk.java.net/jdk/pull/7696

From jpai at openjdk.java.net  Fri Mar  4 14:54:05 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 4 Mar 2022 14:54:05 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <1IGxBt9tVPyAgq03cWyY6ME2yuZOHJYpej3A1rhp_lg=.2cbeadb1-831c-4e02-a5b8-ecf4ba1b54ce@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <77w1_8yIYvMSLVO-m-jwCpuT9wpI1aFjt9tw8TRb1Jc=.d23ace14-4993-4720-93fd-e12aeff52243@github.com>
 <1IGxBt9tVPyAgq03cWyY6ME2yuZOHJYpej3A1rhp_lg=.2cbeadb1-831c-4e02-a5b8-ecf4ba1b54ce@github.com>
Message-ID: <1bn1IMSLVRnlbgkXPTRBNJumESnDdpYYO0gfMe02Qvo=.24dacf0f-501a-49df-a656-5bbc3eea6b76@github.com>

On Fri, 4 Mar 2022 14:06:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/doc-files/net-properties.html line 227:
>> 
>>> 225: 	      name.</P>
>>> 226: 	</OL>
>>> 227: 	<LI><P><B>{@systemProperty http.auth.digest.reEnabledAlgs}</B> (default: &lt;none&gt;)<BR>
>> 
>> Hello Michael, from what I understand of `doc-files` directory (which is where this html file resides) the `javadoc` tool considers it an unprocessed files location[1]. So would adding the `systemProperty` javadoc taglet here be necessary? I think this won't end up being listed in the system properties index generated by the javadoc tool and I think this line here will just get rendered literally.
>> 
>> [1] https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html
>
> This actually seems to work. If you build the docs for JDK mainline, you can search for instance, for `http.keepAlive.time.proxy` in the javadoc search box and it will lead you `net-properties.html`.

You are right indeed. I just checked the generated system properties index and it does list these properties and even links back to this document. In fact, I even found a mail which clearly states that this processing of `@systemProperties` is supported for `doc-files` https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056653.html

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Fri Mar  4 15:00:00 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 4 Mar 2022 15:00:00 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <j66511JYJ8Zhid3D89lL6Ci1rp-t4upIhljydnY1Hd0=.156fc3d7-ab9b-41dc-beff-351be0ca85b0@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <j66511JYJ8Zhid3D89lL6Ci1rp-t4upIhljydnY1Hd0=.156fc3d7-ab9b-41dc-beff-351be0ca85b0@github.com>
Message-ID: <078GV9CX_aqW4yp8oI5lfyrJilt8kZEbKMSrdsQVTzA=.b70f2f23-b43a-4b9c-9c12-006ccb94612b@github.com>

On Fri, 4 Mar 2022 14:39:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 423:
> 
>> 421:         String algorithm = params.getAlgorithm ();
>> 422:         boolean userhash = params.getUserhash ();
>> 423:         params.incrementNC ();
> 
> I am not familiar with the code and the request/response flow involved in this code, so what I mention may not be relevant. However, do you think the algorithm validation that we added in this PR should happen before this `incrementNC()` is called and the `ncString`  construction is done? I see that this incremented `ncCount` then gets used in the `checkResponse` part. In the case where the algorithm validation fails and we return `null` from this method (which effectively means not setting the authorization header), do you think the subsequent `checkResponse` would run into issues due to the `incrementNC()` being done here?

I think there probably wouldn't be a problem as the value would always be increasing and the server is only checking for duplicates, or replays rather than gaps. But, nevertheless, it seems like better practice to do the check before incrementing the counter.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michael.x.mcmahon at oracle.com  Fri Mar  4 15:07:49 2022
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 4 Mar 2022 15:07:49 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <AM9P193MB1142498D78B514FEDE420821FF059@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <yqvrz-W3cux_hmaHECFJjG6knx2QzmrILiFU6K3PMUY=.57c2e36a-51c8-45fc-a2b0-88e317187ecc@github.com>
 <AM9P193MB1142498D78B514FEDE420821FF059@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
Message-ID: <e2084906-80ab-13f2-3926-8bd282851410@oracle.com>

Bernd,

If I understand you correctly, there is no negotiation at this level. 
Once Digest is selected, it's up to the server to choose the algorithm 
and then the client can either accept it or else reject it and the whole 
request fails then.

It's true that with this change, if the server proposes MD5 by default, 
then the request will fail. But, that's the point of the change, and the 
compatibility impact is considered in the related CSR. In that case, 
either the server needs to change or else the system property to 
re-enable MD5 must be set.

I'd like to try out (for the next review round) the idea of establishing 
the default "insecure" protocols as a fixed security property (including 
MD5 and SHA-1) and then provide a settable system or networking property 
to override that.

Thanks

Michael

On 04/03/2022 14:03, Bernd Eckenfels wrote:
> Hello,
>
> While I like the idea of the user having to explicitely specify the rexenabled legacy algorithms (as opposed to removing the defaultsdisabled) it is not the style the other algorithm policies in JCE work - so it might be confusing.
>
> But, more critically I would separate the enabling/implementing of new algorithms from disabling old ones. Especially since there needs to be changes on the server side first. (And I wonder if this can be negotiated anyway?).
>
> So why not start with a ?provide new DIGEST Mechanisms? change? Having said that, would it need to start out with disabled new mechanisms so the update won?t change the behavior? (If there is no negotiation?)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: net-dev<net-dev-retn at openjdk.java.net>  im Auftrag von Michael McMahon<michaelm at openjdk.java.net>
> Gesendet: Friday, March 4, 2022 1:33:06 PM
> An:net-dev at openjdk.java.net  <net-dev at openjdk.java.net>
> Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
>
> On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon<michaelm at openjdk.org>  wrote:
>
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>
>> - Michael
>>>> I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
>>>> I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
>>>
>>> Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
>> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
>>
>> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
>
>
>>>> I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
>>>> I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.
>>>
>>> Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property
>> In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.
>>
>> So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.
> Thinking about it again, I wonder if we should just deprecate SHA-1 at the same time. I think there will be less compatibility impact than with MD5, and it's basically broken as well. I don't see a reason to opt out of other algorithms at this time.
>
> -------------
>
> PR:https://git.openjdk.java.net/jdk/pull/7688
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20220304/0defc7e3/attachment-0001.htm>

From ccleary at openjdk.java.net  Fri Mar  4 15:20:05 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 4 Mar 2022 15:20:05 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large
In-Reply-To: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
Message-ID: <LG84GELxJbU0VqT6VNjmngSQ3lhJFYyZ2T8goAylYs4=.53947158-c367-4416-acf1-bfb62b376daf@github.com>

On Fri, 4 Mar 2022 14:42:40 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> **Problem**
> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
> 
> 
> java.io.IOException: no statuscode in response
> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
> ...
> 
> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
> 
> **Fix**
> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
> 
> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
> 
> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.

I see that a couple of imports got changed by my IDE, will address that shortly

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From mullan at openjdk.java.net  Fri Mar  4 16:32:09 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 4 Mar 2022 16:32:09 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v18]
In-Reply-To: <ewHj78abz54Drk1YXj7HeUvqR5Y8WBqOOd5SvS3Tl8M=.dbb12bc6-72f2-474f-b7e3-a04efef3915b@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <ewHj78abz54Drk1YXj7HeUvqR5Y8WBqOOd5SvS3Tl8M=.dbb12bc6-72f2-474f-b7e3-a04efef3915b@github.com>
Message-ID: <hCQDZHRPtnmaJ64kttJtaostmDPXQMeQc7-Br409fms=.ad682437-46ce-4f09-ab6b-0cbfc8553a1f@github.com>

On Thu, 17 Feb 2022 18:57:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494
>> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more spec update per CSR feedback

Since this new API is also intended to be supported for DTLS, have you added implementation support for that, and if so have you added a test for it?

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

PR: https://git.openjdk.java.net/jdk/pull/7252

From weijun at openjdk.java.net  Fri Mar  4 16:35:00 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 4 Mar 2022 16:35:00 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <anHW0t-4KnemkkaUn-1lr_ogFC8ozGv26Gdi9QR2pUU=.0f6239bd-5585-4130-8a3a-8269943d92f4@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

Several comments added. Also, I am reading rfc7616 and it will be really nice if we can include the 2 examples at https://datatracker.ietf.org/doc/html/rfc7616#section-3.9 as a known answer test. Of course this means you need a way to provide a hardcoded `cnonce` and it's probably not easy.

src/java.base/share/classes/java/net/doc-files/net-properties.html line 232:

> 230:         includes {@code MD5} but other algorithms may be added in future. If it is still
> 231:         required to use one of these algorithms, then they can be re-enabled by setting
> 232:         this property to a comma separated list of the algorithm names.</P>

Is it necessary to emphasize that no whitespace is allowed around the comma in the property value? Or is it better to modify the implementation below to allow whitespaces? I notice that whitespace is allowed in some of the other properties. For example: https://github.com/openjdk/jdk/blob/de3113b998550021bb502cd6f766036fb8351e7d/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L228

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 75:

> 73:     // A net property which overrides the disabled set above.
> 74:     private static final String enabledAlgPropName = "http.auth.digest." +
> 75:         "reEnabledAlgs";

Why not put the string on one line?

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 658:

> 656:     // truncate256 means only use the last 256 bits of the digest (32 bytes)
> 657:     private String encode(String src, char[] passwd, MessageDigest md, boolean truncate256) {
> 658:         md.update(src.getBytes(ISO_8859_1.INSTANCE));

Maybe we can support the "charset" parameter as well. The only allowed value is "UTF-8".

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 670:

> 668:         if (truncate256) {
> 669:             assert digest.length >= 32;
> 670:             start = digest.length - 32;

Does this mean the left half is truncated? My understanding is that the right half should be.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From duke at openjdk.java.net  Fri Mar  4 16:56:25 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 16:56:25 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of
 lines
Message-ID: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>

Hi

I have reviewed the code for removing double semicolons at the end of lines

all the best
matteo

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

Commit messages:
 - Removed double semicolon at the end of lines

Changes: https://git.openjdk.java.net/jdk/pull/7268/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7268&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282657
  Stats: 93 lines in 82 files changed: 0 ins; 0 del; 93 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7268.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7268/head:pull/7268

PR: https://git.openjdk.java.net/jdk/pull/7268

From duke at openjdk.java.net  Fri Mar  4 16:56:25 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 16:56:25 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Hi

I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted.
Now: what is the next step?

This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code.

ciao
matteo

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From jwaters at openjdk.java.net  Fri Mar  4 16:56:26 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Fri, 4 Mar 2022 16:56:26 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>
Message-ID: <lG5726a2a2WsQQRwKZ-SUq00bw3xlHNvLwgcYapsIY4=.d0ad6d98-14f6-4f55-b06c-fe24dc042505@github.com>

On Fri, 25 Feb 2022 15:40:09 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> Hi
> 
> I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted.
> Now: what is the next step?
> 
> This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code.
> 
> ciao
> matteo

Hi @matteobaccan

The next step would be to create a relevant issue on the tracker and set it to track this PR. Since you don't have the ability to create new issues on the JBS yet I'll help you create one, please rename your PR title to 8282657 and the system should take care of the rest and automatically mark your PR as ready for review after setting it to track the corresponding JBS entry.

Cheers,
Julian

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From lancea at openjdk.java.net  Fri Mar  4 17:07:59 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Mar 2022 17:07:59 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <e7XmpMjRNztZjXRaLS_7w4v_zyHgRMOWuaP-uvgHc8U=.1fabaeab-3387-4056-8b46-6851ef81c0d3@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

The changes look OK.  The copyright year probably should be updated as part of this PR

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

From duke at openjdk.java.net  Fri Mar  4 17:14:05 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 17:14:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <Z5IUTXYy0jJDvo942sQbkENuPE1poTsr0KXGmlNjK-8=.4b7a9484-d07e-4582-8f09-532018f06875@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Hi Lance

I can make a second commit updating the copyright year

Tell me if this is necessary

ciao
matteo

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From rriggs at openjdk.java.net  Fri Mar  4 17:20:05 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 17:20:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain.  The client modules are usually separated out, as are hotspot.
And corresponding tests.
This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers.
If you had ask ahead of time, I would have suggested finding something with more value.

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

Changes requested by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

From ihse at openjdk.java.net  Fri Mar  4 17:50:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Mar 2022 17:50:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>
Message-ID: <uclpoZxrJsB8HaLQGJ4mOFL-PlE1VkzzSiFYVX9Xu74=.cf93ab56-6689-4c02-aaed-db24b78811b5@github.com>

On Fri, 4 Mar 2022 17:17:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain.  The client modules are usually separated out, as are hotspot.
> And corresponding tests.
> This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers.
> If you had ask ahead of time, I would have suggested finding something with more value.

@RogerRiggs Otoh, this change is really trivial. I have verified that all changes are replacing trailing ";;" in Java code. These are all clearly typos. I think it's nice that we try to strive for a high quality, and while you are correct this is maybe not the most pressing issue, I think it's nice to get a cleanup like this done. 

I'd argue that this is a trivial change. If you are worried, let's get a couple of more reviewers. I can't see the need to split this up per area.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From prr at openjdk.java.net  Fri Mar  4 19:10:06 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 19:10:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <flAiYSlXjGXC4cguwLIZyH5aNm_n_wHhhiUVZLnQHOw=.55037371-dfc6-481a-965a-703b845542ad@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by prr (Reviewer).

Looks like  there's only one client source code file touched
Most of the client changes are only in jtreg tests - and this is very trivial, so I'm OK with them being included here.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From rriggs at openjdk.java.net  Fri Mar  4 19:33:06 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 19:33:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <w6EtpBynowVBiw_b5nP_UIAIXBanT3tU4iu5g8_e4gM=.24ccf09a-048f-4308-ac77-a8412eb61b71@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From iris at openjdk.java.net  Fri Mar  4 19:43:03 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 4 Mar 2022 19:43:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <MATEadXGlyHBObaz0cYBJT19VmXa5Sk_VcaOKC_AtE8=.c1394e50-8bc7-44ab-bcec-8f3701295187@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Nice tidy of the code.

Is there anything that can be done to prevent re-introduction of this trivial problem?  Perhaps a new Skara bot jcheck option similar to what is already in place for trailing whitespace?

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

From wetmore at openjdk.java.net  Fri Mar  4 19:56:03 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 4 Mar 2022 19:56:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <1X39o4ON1uvbSXAp_r66zAmSy6sWZFKaP7-M54vAqX0=.d6abe0d5-9dd2-409b-91df-255d838196cb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

LGTM also.  

Similar suggestion for updating copyrights.

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

From ecki at zusammenkunft.net  Fri Mar  4 20:50:50 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 4 Mar 2022 20:50:50 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <e2084906-80ab-13f2-3926-8bd282851410@oracle.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <yqvrz-W3cux_hmaHECFJjG6knx2QzmrILiFU6K3PMUY=.57c2e36a-51c8-45fc-a2b0-88e317187ecc@github.com>
 <AM9P193MB1142498D78B514FEDE420821FF059@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <e2084906-80ab-13f2-3926-8bd282851410@oracle.com>
Message-ID: <AM9P193MB11424C8F862AF73189DA3131FF059@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Thanks for the clarification Michael,

I was actually wrongly assuming that the client has to propose the method. If the server can do that, then it is relative risk free to support additional algorithms on the client side (and ignore a challenge if it requests disabled algorithm (this would include md5 default for absent attribute)).

Did not know the WWW-Authenticate header does that.

Still I would Seperate the md5 deprecation from the implementation of alternative algorithms to make a larger cut-over window (maybe even schedule it in the Oracle crypto roadmap)

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: Michael McMahon <michael.x.mcmahon at oracle.com>
Gesendet: Friday, March 4, 2022 4:07:49 PM
An: Bernd Eckenfels <ecki at zusammenkunft.net>; net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default


Bernd,

If I understand you correctly, there is no negotiation at this level. Once Digest is selected, it's up to the server to choose the algorithm and then the client can either accept it or else reject it and the whole request fails then.

It's true that with this change, if the server proposes MD5 by default, then the request will fail. But, that's the point of the change, and the compatibility impact is considered in the related CSR. In that case, either the server needs to change or else the system property to re-enable MD5 must be set.

I'd like to try out (for the next review round) the idea of establishing the default "insecure" protocols as a fixed security property (including MD5 and SHA-1) and then provide a settable system or networking property to override that.

Thanks

Michael

On 04/03/2022 14:03, Bernd Eckenfels wrote:

Hello,

While I like the idea of the user having to explicitely specify the rexenabled legacy algorithms (as opposed to removing the defaultsdisabled) it is not the style the other algorithm policies in JCE work - so it might be confusing.

But, more critically I would separate the enabling/implementing of new algorithms from disabling old ones. Especially since there needs to be changes on the server side first. (And I wonder if this can be negotiated anyway?).

So why not start with a ?provide new DIGEST Mechanisms? change? Having said that, would it need to start out with disabled new mechanisms so the update won?t change the behavior? (If there is no negotiation?)

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: net-dev <net-dev-retn at openjdk.java.net><mailto:net-dev-retn at openjdk.java.net> im Auftrag von Michael McMahon <michaelm at openjdk.java.net><mailto:michaelm at openjdk.java.net>
Gesendet: Friday, March 4, 2022 1:33:06 PM
An: net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net> <net-dev at openjdk.java.net><mailto:net-dev at openjdk.java.net>
Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org><mailto:michaelm at openjdk.org> wrote:



Hi,

Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.

- Michael





I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.




Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property



In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.

So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.







I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames=""
I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name.




Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property



In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point.

So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in.



Thinking about it again, I wonder if we should just deprecate SHA-1 at the same time. I think there will be less compatibility impact than with MD5, and it's basically broken as well. I don't see a reason to opt out of other algorithms at this time.

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

PR: https://git.openjdk.java.net/jdk/pull/7688


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20220304/668b14e2/attachment.htm>

From darcy at openjdk.java.net  Fri Mar  4 21:23:30 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Mar 2022 21:23:30 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to SocketException
Message-ID: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>

Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.

Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

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

Commit messages:
 - JDK-8282686: Add constructors take a cause to SocketException

Changes: https://git.openjdk.java.net/jdk/pull/7705/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282686
  Stats: 48 lines in 6 files changed: 23 ins; 12 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7705.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7705/head:pull/7705

PR: https://git.openjdk.java.net/jdk/pull/7705

From darcy at openjdk.java.net  Fri Mar  4 21:33:07 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Mar 2022 21:33:07 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <Fk4CQf_wtrFu81GCs38UEX3qnk9nz3DUkP7EZT37icU=.78ef4ece-fe43-4b9a-b4c4-393e7bf741cb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From wetmore at openjdk.java.net  Fri Mar  4 23:47:07 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 4 Mar 2022 23:47:07 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v2]
In-Reply-To: <j4sqdo5vLlBwWSUNCpQEzns9tlaPY2ORgxEtJ7yhmfA=.d9a984be-82c6-4bfa-8632-56ced31828ab@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <j4sqdo5vLlBwWSUNCpQEzns9tlaPY2ORgxEtJ7yhmfA=.d9a984be-82c6-4bfa-8632-56ced31828ab@github.com>
Message-ID: <V1YL5fqQGJDv8Ie_92pze5F52zj_mMdxI6YJnW9s9VE=.75831831-d52c-40ba-aa5c-f1b4a2c92ca0@github.com>

On Thu, 3 Mar 2022 12:36:33 GMT, zzambers <duke at openjdk.java.net> wrote:

>> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
>> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright for SSLSocket.java

There are more changes needed, and should probably be done as part of this issue since we're already in this code anyway.  The current code only talks about shutdownInput/shutdownOutput, but makes no mention of the duplex close(), which is the other way to shutdown the SSLSocket.  It only needs a few words.

https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029167.html

These two changes will require a CSR to update the @apiNote.

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From dholmes at openjdk.java.net  Sat Mar  5 05:52:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 5 Mar 2022 05:52:04 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <2NJw-71OOOvNs9519H__uYdXQnJm23L-Ez4jKoAuKrk=.c277d644-fd63-442e-99a1-6d3d66cb3405@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

I eyeballed the diff file and all seems okay.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

From jwaters at openjdk.java.net  Sat Mar  5 06:52:13 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Sat, 5 Mar 2022 06:52:13 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Nice, good work matteo

Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From duke at openjdk.java.net  Sat Mar  5 07:22:03 2022
From: duke at openjdk.java.net (Jan =?UTF-8?B?U2NobMO2w59pbg==?=)
Date: Sat, 5 Mar 2022 07:22:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <apFWxhCWJTH2dzbDsF-uJEef-Y6uhfH0gNI48VGHYwU=.8dfe6837-793d-466f-bb16-9f7fd53798d8@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

This PR changes a comment in javax/swing/RepaintManager.java. This commented out code should be removed altogether in another PR? Because its an System.out.println and because its commented out code.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From alanb at openjdk.java.net  Sat Mar  5 09:50:03 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 5 Mar 2022 09:50:03 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <whh8xzBSXj_-Fvwx9HTLhxx_9HOu6nKFtEoufQjOFTo=.900c1c38-6603-414f-ae51-30f1acbc8304@github.com>

On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

This looks good, I just wonder if we should add a test for the new constructors. One of them will be tested by the usages in the JDK, the cause-only constructor may not be exercised by any code.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7705

From jpai at openjdk.java.net  Sat Mar  5 15:11:06 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 5 Mar 2022 15:11:06 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <fOVMbPn1_M5-sCxCbNIsovrCOuHj-Cgj8_nnBOPt4ww=.d321ff6f-ba2a-4b23-90bc-d0e9bf3df200@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 514:

> 512:         if (getAuthType() == AuthCacheValue.Type.Server &&
> 513:                 getProtocolScheme().equals("https")) {
> 514:             // HTTPS server authentication can use any algorithm

Hello Michael,
Should it be noted somewhere in the text of the linked CSR that the property values play no role if the request URL's scheme is HTTPS (and proxy isn't involved)?

As a related question - should the implementation even bother about this HTTP vs HTTPS protocol check? As far as I understand, the reason why we are proposing to disable support for MD5 is because of its cryptographic weakness/vulnerabilities. So irrespective of whether or not the  computed MD5 (or any other disabled algorithm) digest value gets transferred over HTTP or HTTPS, the value would still be cryptographically vulnerable isn't it?

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From xuelei at openjdk.java.net  Sat Mar  5 16:16:55 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 5 Mar 2022 16:16:55 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <6YOD-AAXJFwPkF-qNokBEUTyQaX2BnN4MIXPnuGng-4=.b1a042d3-b548-4fd4-bacf-45aa8f4cb315@github.com>

On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

Looks good to me.  I may file a new RFE and use this constructor in the JSSE implementation.

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

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7705

From lancea at openjdk.java.net  Sat Mar  5 16:48:59 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 5 Mar 2022 16:48:59 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <rUDb3aB5W3eMeDOo2bRpN4CyO7yJ3oqy0aI32FI0Kf0=.f56555df-131e-4be0-a972-c2b8494a65db@github.com>

On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

Looks fine, would be worth including a couple of tests for coverage

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7705

From xuelei at openjdk.java.net  Sun Mar  6 05:40:59 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 6 Mar 2022 05:40:59 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v19]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <V6Ww8N15wiAjzdoYuLZWkJX3EzgMZKXr0X6mx5wpDwc=.26adf6c5-8668-4ef0-815e-c5772b095fe8@github.com>

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494
> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  add test for DTLS

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/5a98c921..ca006ee0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=17-18

  Stats: 134 lines in 1 file changed: 134 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7252.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7252/head:pull/7252

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Sun Mar  6 05:40:59 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 6 Mar 2022 05:40:59 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v18]
In-Reply-To: <hCQDZHRPtnmaJ64kttJtaostmDPXQMeQc7-Br409fms=.ad682437-46ce-4f09-ab6b-0cbfc8553a1f@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <ewHj78abz54Drk1YXj7HeUvqR5Y8WBqOOd5SvS3Tl8M=.dbb12bc6-72f2-474f-b7e3-a04efef3915b@github.com>
 <hCQDZHRPtnmaJ64kttJtaostmDPXQMeQc7-Br409fms=.ad682437-46ce-4f09-ab6b-0cbfc8553a1f@github.com>
Message-ID: <LvPzW6MH0n8dRdNKzesShmlTPrP99ArIolsA0Q_gR6A=.f772c4bb-c8b9-4589-b9af-3fdd2a869f00@github.com>

On Fri, 4 Mar 2022 16:29:04 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Since this new API is also intended to be supported for DTLS, have you added implementation support for that, and if so have you added a test for it?

Yes, the DTLS implementation is included.  I added a test case for DTLS.

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

PR: https://git.openjdk.java.net/jdk/pull/7252

From jpai at openjdk.java.net  Sun Mar  6 06:43:00 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 6 Mar 2022 06:43:00 GMT
Subject: RFR: 8282617:
 sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a
 lock while dealing with inCache field
In-Reply-To: <vuYABjn2JkRldKtKcFn8X4otQv5ob-DNJ3gVEe2uLLw=.dcb1c006-732c-4410-938d-9c25c94345d4@github.com>
References: <vuYABjn2JkRldKtKcFn8X4otQv5ob-DNJ3gVEe2uLLw=.dcb1c006-732c-4410-938d-9c25c94345d4@github.com>
Message-ID: <HgkQLradp19C2pO8AQskCQH3Dv2XzchI-jqPVy6RVuw=.4e3268e4-bfeb-4ebc-92f0-f9d1af55d1b8@github.com>

On Thu, 3 Mar 2022 16:13:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282617? 
> 
> The `HttpClient` class uses a `inCache` (internal) field to keep track of whether a connection is in the keep-alive cache. This is a mutable field and when dealing with this field the `HttpClient` class uses a lock.
> 
> The `HttpsClient` class extends this `HttpClient` class. It additionally overrides the `putInKeepAliveCache()` method to use a Https specific way of populating the keep alive cache. While doing so it also reads and updates the `inCache` `protected` field from its super `HttpClient` class, but doesn't use a lock to do so. This can thus cause a race condition when the `inCache` field gets accessed concurrently, for example a separate thread calling the `HttpClient#isInKeepAliveCache()` method.
> 
> To fix this issue, the commit here uses the same lock/unlock construct used in the `HttpClient` super class.

Thank you Michael and Daniel for the reviews. The tier1 and tier2 testing came back as successful.

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

PR: https://git.openjdk.java.net/jdk/pull/7680

From jpai at openjdk.java.net  Sun Mar  6 08:20:05 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 6 Mar 2022 08:20:05 GMT
Subject: Integrated: 8282617:
 sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a
 lock while dealing with "inCache" field
In-Reply-To: <vuYABjn2JkRldKtKcFn8X4otQv5ob-DNJ3gVEe2uLLw=.dcb1c006-732c-4410-938d-9c25c94345d4@github.com>
References: <vuYABjn2JkRldKtKcFn8X4otQv5ob-DNJ3gVEe2uLLw=.dcb1c006-732c-4410-938d-9c25c94345d4@github.com>
Message-ID: <WBmhRYxvbA0trnO0gM7L8UcvYEq9sRv3gdwgEqApdoM=.14d88323-5206-4561-a464-f48d86aa0dae@github.com>

On Thu, 3 Mar 2022 16:13:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282617? 
> 
> The `HttpClient` class uses a `inCache` (internal) field to keep track of whether a connection is in the keep-alive cache. This is a mutable field and when dealing with this field the `HttpClient` class uses a lock.
> 
> The `HttpsClient` class extends this `HttpClient` class. It additionally overrides the `putInKeepAliveCache()` method to use a Https specific way of populating the keep alive cache. While doing so it also reads and updates the `inCache` `protected` field from its super `HttpClient` class, but doesn't use a lock to do so. This can thus cause a race condition when the `inCache` field gets accessed concurrently, for example a separate thread calling the `HttpClient#isInKeepAliveCache()` method.
> 
> To fix this issue, the commit here uses the same lock/unlock construct used in the `HttpClient` super class.

This pull request has now been integrated.

Changeset: 974ef554
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/974ef5542fe52f9cb8ffd8751df8a020bca503c9
Stats:     13 lines in 1 file changed: 7 ins; 2 del; 4 mod

8282617: sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a lock while dealing with "inCache" field

Reviewed-by: dfuchs, michaelm

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

PR: https://git.openjdk.java.net/jdk/pull/7680

From xuelei at openjdk.java.net  Mon Mar  7 08:03:29 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Mar 2022 08:03:29 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
Message-ID: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>

Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.

Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724

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

Commit messages:
 - 8282723: Add constructors taking a cause to JSSE exceptions

Changes: https://git.openjdk.java.net/jdk/pull/7722/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282723
  Stats: 174 lines in 19 files changed: 64 ins; 48 del; 62 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7722/head:pull/7722

PR: https://git.openjdk.java.net/jdk/pull/7722

From ccleary at openjdk.java.net  Mon Mar  7 08:23:46 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Mar 2022 08:23:46 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v2]
In-Reply-To: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
Message-ID: <p9reBBHP0p7l4xxPRfKFKl_At-RLmVS2eHRdevXZtH0=.9d03c1cf-b752-4286-bc48-5447a768b976@github.com>

> **Problem**
> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
> 
> 
> java.io.IOException: no statuscode in response
> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
> ...
> 
> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
> 
> **Fix**
> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
> 
> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
> 
> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.

Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:

  8263031: Tidied up import statements

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7696/files
  - new: https://git.openjdk.java.net/jdk/pull/7696/files/527cfacb..664a1105

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=00-01

  Stats: 35 lines in 1 file changed: 31 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7696.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7696/head:pull/7696

PR: https://git.openjdk.java.net/jdk/pull/7696

From ccleary at openjdk.java.net  Mon Mar  7 08:23:47 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Mar 2022 08:23:47 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large
In-Reply-To: <LG84GELxJbU0VqT6VNjmngSQ3lhJFYyZ2T8goAylYs4=.53947158-c367-4416-acf1-bfb62b376daf@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <LG84GELxJbU0VqT6VNjmngSQ3lhJFYyZ2T8goAylYs4=.53947158-c367-4416-acf1-bfb62b376daf@github.com>
Message-ID: <vDwatJnS-cLbTDwTskTiO8XMlVWJW58djG5SAJvJuLc=.d67657d1-7619-42b4-bfd2-76d3e9e91146@github.com>

On Fri, 4 Mar 2022 15:17:11 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> I see that a couple of imports got changed by my IDE, will address that shortly

Now resolved

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From dfuchs at openjdk.java.net  Mon Mar  7 10:27:58 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Mar 2022 10:27:58 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <l0Yr3D_QlBy1O-AbjUUcmjNNwrCJ89imHf8CaLReDcY=.68c93ed3-66eb-4d37-b091-7cc5748c367c@github.com>

On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7705

From michaelm at openjdk.java.net  Mon Mar  7 11:04:02 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 7 Mar 2022 11:04:02 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <anHW0t-4KnemkkaUn-1lr_ogFC8ozGv26Gdi9QR2pUU=.0f6239bd-5585-4130-8a3a-8269943d92f4@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <anHW0t-4KnemkkaUn-1lr_ogFC8ozGv26Gdi9QR2pUU=.0f6239bd-5585-4130-8a3a-8269943d92f4@github.com>
Message-ID: <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>

On Fri, 4 Mar 2022 14:59:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> src/java.base/share/classes/java/net/doc-files/net-properties.html line 232:
> 
>> 230:         includes {@code MD5} but other algorithms may be added in future. If it is still
>> 231:         required to use one of these algorithms, then they can be re-enabled by setting
>> 232:         this property to a comma separated list of the algorithm names.</P>
> 
> Is it necessary to emphasize that no whitespace is allowed around the comma in the property value? Or is it better to modify the implementation below to allow whitespaces? I notice that whitespace is allowed in some of the other properties. For example: https://github.com/openjdk/jdk/blob/de3113b998550021bb502cd6f766036fb8351e7d/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L228

Right, probably better to allow whitespace, which seems to be commonly used in the existing security properties

> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 75:
> 
>> 73:     // A net property which overrides the disabled set above.
>> 74:     private static final String enabledAlgPropName = "http.auth.digest." +
>> 75:         "reEnabledAlgs";
> 
> Why not put the string on one line?

I'll try and see if it fits the normal line width

> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 670:
> 
>> 668:         if (truncate256) {
>> 669:             assert digest.length >= 32;
>> 670:             start = digest.length - 32;
> 
> Does this mean the left half is truncated? My understanding is that the right half should be.

Okay, I'll double check that. I haven't found any server implementations of this feature to test with yet,

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From ecki at zusammenkunft.net  Mon Mar  7 11:27:45 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Mon, 7 Mar 2022 11:27:45 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <anHW0t-4KnemkkaUn-1lr_ogFC8ozGv26Gdi9QR2pUU=.0f6239bd-5585-4130-8a3a-8269943d92f4@github.com>
 <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
Message-ID: <AM9P193MB1142EDF84300E3AC7948BAECFF089@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Hello,

SHA-512/256 is normally not a simple truncation (because similiar hashes are not a robust crypto practice, instead it is using different initialisation vectors).

Haven?t checked the example vectors in rfc 7616, but I would asume they refer to FIPS 180-4 truncation variants.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: net-dev <net-dev-retn at openjdk.java.net> im Auftrag von Michael McMahon <michaelm at openjdk.java.net>
Gesendet: Monday, March 7, 2022 12:04:02 PM
An: net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default

On Fri, 4 Mar 2022 14:59:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>
>> - Michael
>
> src/java.base/share/classes/java/net/doc-files/net-properties.html line 232:
>
>> 230:         includes {@code MD5} but other algorithms may be added in future. If it is still
>> 231:         required to use one of these algorithms, then they can be re-enabled by setting
>> 232:         this property to a comma separated list of the algorithm names.</P>
>
> Is it necessary to emphasize that no whitespace is allowed around the comma in the property value? Or is it better to modify the implementation below to allow whitespaces? I notice that whitespace is allowed in some of the other properties. For example: https://github.com/openjdk/jdk/blob/de3113b998550021bb502cd6f766036fb8351e7d/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L228

Right, probably better to allow whitespace, which seems to be commonly used in the existing security properties

> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 75:
>
>> 73:     // A net property which overrides the disabled set above.
>> 74:     private static final String enabledAlgPropName = "http.auth.digest." +
>> 75:         "reEnabledAlgs";
>
> Why not put the string on one line?

I'll try and see if it fits the normal line width

> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 670:
>
>> 668:         if (truncate256) {
>> 669:             assert digest.length >= 32;
>> 670:             start = digest.length - 32;
>
> Does this mean the left half is truncated? My understanding is that the right half should be.

Okay, I'll double check that. I haven't found any server implementations of this feature to test with yet,

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

PR: https://git.openjdk.java.net/jdk/pull/7688
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20220307/cfc0c761/attachment.htm>

From ccleary at openjdk.java.net  Mon Mar  7 11:41:05 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 7 Mar 2022 11:41:05 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v2]
In-Reply-To: <p9reBBHP0p7l4xxPRfKFKl_At-RLmVS2eHRdevXZtH0=.9d03c1cf-b752-4286-bc48-5447a768b976@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <p9reBBHP0p7l4xxPRfKFKl_At-RLmVS2eHRdevXZtH0=.9d03c1cf-b752-4286-bc48-5447a768b976@github.com>
Message-ID: <td9L-LPu6FHX3CjhqgvmhRJnRtDK_hyoLR_E-qH9KMM=.233e1229-b999-4729-8dd2-e8a12fb17997@github.com>

On Mon, 7 Mar 2022 08:23:46 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Problem**
>> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
>> 
>> 
>> java.io.IOException: no statuscode in response
>> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
>> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
>> ...
>> 
>> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
>> 
>> **Fix**
>> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
>> 
>> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
>> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
>> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
>> 
>> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263031: Tidied up import statements

test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 227:

> 225:             map.put("x-promise", List.of(mainPromiseBody));
> 226:             HttpHeaders headers = HttpHeaders.of(map, ACCEPT_ALL);
> 227:             exchange.serverPush(uri, headers, is);

Could create all of the headers here instead of in Http2LPPTestExchangeImpl, might improve readability of test.

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From michaelm at openjdk.java.net  Mon Mar  7 12:00:59 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 7 Mar 2022 12:00:59 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <anHW0t-4KnemkkaUn-1lr_ogFC8ozGv26Gdi9QR2pUU=.0f6239bd-5585-4130-8a3a-8269943d92f4@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <anHW0t-4KnemkkaUn-1lr_ogFC8ozGv26Gdi9QR2pUU=.0f6239bd-5585-4130-8a3a-8269943d92f4@github.com>
Message-ID: <xeEGKEnMAHFWg84r72GBXClN7xZnbmuTTH_tIPNowc0=.a146ae6c-15cd-4c15-9cc5-29151a82144c@github.com>

On Fri, 4 Mar 2022 16:26:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 658:
> 
>> 656:     // truncate256 means only use the last 256 bits of the digest (32 bytes)
>> 657:     private String encode(String src, char[] passwd, MessageDigest md, boolean truncate256) {
>> 658:         md.update(src.getBytes(ISO_8859_1.INSTANCE));
> 
> Maybe we can support the "charset" parameter as well. The only allowed value is "UTF-8".

I'll look into supporting that.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Mon Mar  7 12:09:04 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Mar 2022 12:09:04 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID: <D65VhFkEzuQJZD2FvYzqw_IiQGo871FkkuJL-7IwQok=.bca666d6-1623-4254-9cc6-8a82ff6b5c89@github.com>

On Mon, 7 Mar 2022 07:52:29 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
> 
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724

LGTM. Someone from security-dev should probably review this too.

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From michaelm at openjdk.java.net  Mon Mar  7 12:24:08 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 7 Mar 2022 12:24:08 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <fOVMbPn1_M5-sCxCbNIsovrCOuHj-Cgj8_nnBOPt4ww=.d321ff6f-ba2a-4b23-90bc-d0e9bf3df200@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <fOVMbPn1_M5-sCxCbNIsovrCOuHj-Cgj8_nnBOPt4ww=.d321ff6f-ba2a-4b23-90bc-d0e9bf3df200@github.com>
Message-ID: <bHwhIDMgSTsnn0-mxp_RDdaK0LomaZxl9DM0JZIpHyk=.ed1bbee7-47b9-4933-8ce4-2061c38a8d79@github.com>

On Sat, 5 Mar 2022 15:07:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 514:
> 
>> 512:         if (getAuthType() == AuthCacheValue.Type.Server &&
>> 513:                 getProtocolScheme().equals("https")) {
>> 514:             // HTTPS server authentication can use any algorithm
> 
> Hello Michael,
> Should it be noted somewhere in the text of the linked CSR that the property values play no role if the request URL's scheme is HTTPS (and proxy isn't involved)?
> 
> As a related question - should the implementation even bother about this HTTP vs HTTPS protocol check? As far as I understand, the reason why we are proposing to disable support for MD5 is because of its cryptographic weakness/vulnerabilities. So irrespective of whether or not the  computed MD5 (or any other disabled algorithm) digest value gets transferred over HTTP or HTTPS, the value would still be cryptographically vulnerable isn't it?

The distinction may be worth mentioning in the CSR and the docs. The distinction is useful because like Basic authentication which is completely insecure with plaintext HTTP, it is secure and a potentially useful web authentication scheme controlled by the browser when run over HTTPS (except when authenticating with HTTPS to a proxy).

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michael.x.mcmahon at oracle.com  Mon Mar  7 12:24:36 2022
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 7 Mar 2022 12:24:36 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <AM9P193MB1142EDF84300E3AC7948BAECFF089@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <anHW0t-4KnemkkaUn-1lr_ogFC8ozGv26Gdi9QR2pUU=.0f6239bd-5585-4130-8a3a-8269943d92f4@github.com>
 <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
 <AM9P193MB1142EDF84300E3AC7948BAECFF089@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
Message-ID: <bfa4c0be-bfa2-224d-a2b2-b906c7516d4d@oracle.com>

Bernd,

In that case we should defer to the security libraries to implement 
SHA-512-256, which does not seem to be supported currently. We already 
support SHA-512 so that should be sufficient at this point.

Thanks

Michael.

On 07/03/2022 11:27, Bernd Eckenfels wrote:
> Hello,
>
> SHA-512/256 is normally not a simple truncation (because similiar hashes are not a robust crypto practice, instead it is using different initialisation vectors).
>
> Haven?t checked the example vectors in rfc 7616, but I would asume they refer to FIPS 180-4 truncation variants.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: net-dev<net-dev-retn at openjdk.java.net>  im Auftrag von Michael McMahon<michaelm at openjdk.java.net>
> Gesendet: Monday, March 7, 2022 12:04:02 PM
> An:net-dev at openjdk.java.net  <net-dev at openjdk.java.net>
> Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
>
> On Fri, 4 Mar 2022 14:59:48 GMT, Weijun Wang<weijun at openjdk.org>  wrote:
>
>>> Hi,
>>>
>>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>>>
>>> - Michael
>> src/java.base/share/classes/java/net/doc-files/net-properties.html line 232:
>>
>>> 230:         includes {@code MD5} but other algorithms may be added in future. If it is still
>>> 231:         required to use one of these algorithms, then they can be re-enabled by setting
>>> 232:         this property to a comma separated list of the algorithm names.</P>
>> Is it necessary to emphasize that no whitespace is allowed around the comma in the property value? Or is it better to modify the implementation below to allow whitespaces? I notice that whitespace is allowed in some of the other properties. For example:https://github.com/openjdk/jdk/blob/de3113b998550021bb502cd6f766036fb8351e7d/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L228
> Right, probably better to allow whitespace, which seems to be commonly used in the existing security properties
>
>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 75:
>>
>>> 73:     // A net property which overrides the disabled set above.
>>> 74:     private static final String enabledAlgPropName = "http.auth.digest." +
>>> 75:         "reEnabledAlgs";
>> Why not put the string on one line?
> I'll try and see if it fits the normal line width
>
>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 670:
>>
>>> 668:         if (truncate256) {
>>> 669:             assert digest.length >= 32;
>>> 670:             start = digest.length - 32;
>> Does this mean the left half is truncated? My understanding is that the right half should be.
> Okay, I'll double check that. I haven't found any server implementations of this feature to test with yet,
>
> -------------
>
> PR:https://git.openjdk.java.net/jdk/pull/7688
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20220307/bee5eac1/attachment-0001.htm>

From dfuchs at openjdk.java.net  Mon Mar  7 12:35:07 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Mar 2022 12:35:07 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v2]
In-Reply-To: <p9reBBHP0p7l4xxPRfKFKl_At-RLmVS2eHRdevXZtH0=.9d03c1cf-b752-4286-bc48-5447a768b976@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <p9reBBHP0p7l4xxPRfKFKl_At-RLmVS2eHRdevXZtH0=.9d03c1cf-b752-4286-bc48-5447a768b976@github.com>
Message-ID: <Kkb44b46Xq1zd6lFgllDvKFVAW_gPbyJGSd7jMUNTZc=.3d600e2b-bbc9-4abd-8d1e-48d4f19b252b@github.com>

On Mon, 7 Mar 2022 08:23:46 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Problem**
>> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
>> 
>> 
>> java.io.IOException: no statuscode in response
>> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
>> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
>> ...
>> 
>> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
>> 
>> **Fix**
>> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
>> 
>> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
>> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
>> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
>> 
>> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263031: Tidied up import statements

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 82:

> 80: import java.util.function.Function;
> 81: import java.util.function.Supplier;
> 82: 

Could we keep the original alphabetical ordering and have the java.* imports come before the jdk.* imports?

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 780:

> 778: 
> 779:                 if (!(frame instanceof ResetFrame)) {
> 780:                     if (frame instanceof DataFrame) {

we could use instanceof pattern matching here to get rid of the cast

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 799:

> 797:             }
> 798: 
> 799:             // While pus frame is not null, the only acceptable frame on this

is there a letter missing in `pus` ?

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 803:

> 801:             if (pcs != null) {
> 802:                 if (frame instanceof ContinuationFrame cf) {
> 803:                     handlePushContinuation(stream, cf);

IOException should probably be caught and transformed in protocol error here to?
In case of protocol error when handling push promise (or their continuation) - should `pcs` be reset to null?
Maybe it doesn't matter since we're closing the connection anyway.

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 805:

> 803:                     handlePushContinuation(stream, cf);
> 804:                 } else {
> 805:                     // TODO: Maybe say what kind of frame was received instead

We should either do it or remove the TODO. @Michael-Mc-Mahon what would you suggest here?

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 855:

> 853: 
> 854:     private record PushContinuationState(HeaderDecoder pushContDecoder, PushPromiseFrame pushContFrame) {}
> 855:     private volatile PushContinuationState pcs;

I'd prefer to have a longer name than `pcs` - `pushContinuationState` would make it less mysterious at the place where it's used.  Also it could be good to move these declarations (linew 854 and 855) higher in the file, where other instance variables are declared.

test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Please add an `@bug 8263031` tag here

test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 33:

> 31:  *          java.net.http/jdk.internal.net.http.hpack
> 32:  * @run testng/othervm PushPromiseContinuation
> 33:  */

It would be good to add an @summary tag to explain the purpose of this test

test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 176:

> 174:             ContinuationFrame cf = new ContinuationFrame(streamid, HeaderFrame.END_HEADERS, encodedHeaders);
> 175: 
> 176:             try {

It would be good to have a test-case that creates 2 continuation frames too.

test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 231:

> 229:         }
> 230:     }
> 231: }

missing newline at end of file?

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From michael.x.mcmahon at oracle.com  Mon Mar  7 12:43:20 2022
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 7 Mar 2022 12:43:20 +0000
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <bfa4c0be-bfa2-224d-a2b2-b906c7516d4d@oracle.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <anHW0t-4KnemkkaUn-1lr_ogFC8ozGv26Gdi9QR2pUU=.0f6239bd-5585-4130-8a3a-8269943d92f4@github.com>
 <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
 <AM9P193MB1142EDF84300E3AC7948BAECFF089@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <bfa4c0be-bfa2-224d-a2b2-b906c7516d4d@oracle.com>
Message-ID: <31668053-0d17-99a9-3feb-2254274790d6@oracle.com>

I'm wrong. It is implemented in the security libs. So, that means we can 
support it also

Michael

On 07/03/2022 12:24, Michael McMahon wrote:
> Bernd,
>
> In that case we should defer to the security libraries to implement 
> SHA-512-256, which does not seem to be supported currently. We already 
> support SHA-512 so that should be sufficient at this point.
>
> Thanks
>
> Michael.
>
> On 07/03/2022 11:27, Bernd Eckenfels wrote:
>> Hello,
>>
>> SHA-512/256 is normally not a simple truncation (because similiar 
>> hashes are not a robust crypto practice, instead it is using 
>> different initialisation vectors).
>>
>> Haven?t checked the example vectors in rfc 7616, but I would asume 
>> they refer to FIPS 180-4 truncation variants.
>>
>> Gruss
>> Bernd
>> -- 
>> http://bernd.eckenfels.net
>> ________________________________
>> Von: net-dev<net-dev-retn at openjdk.java.net>? im Auftrag von Michael 
>> McMahon<michaelm at openjdk.java.net>
>> Gesendet: Monday, March 7, 2022 12:04:02 PM
>> An:net-dev at openjdk.java.net <net-dev at openjdk.java.net>
>> Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by 
>> default
>>
>> On Fri, 4 Mar 2022 14:59:48 GMT, Weijun Wang<weijun at openjdk.org>? wrote:
>>
>>>> Hi,
>>>>
>>>> Could I get the following change reviewed please, which is to 
>>>> disable the MD5 message digest algorithm by default in the HTTP 
>>>> Digest authentication mechanism? The algorithm can be opted into by 
>>>> setting a new system property "http.auth.digest.reEnabledAlgs" to 
>>>> include the value MD5. The change also updates the Digest 
>>>> authentication implementation to use some of the more secure 
>>>> features defined in RFC7616, such as username hashing and 
>>>> additional digest algorithms like SHA256 and SHA512-256.
>>>>
>>>> - Michael
>>> src/java.base/share/classes/java/net/doc-files/net-properties.html 
>>> line 232:
>>>
>>>> 230:???????? includes {@code MD5} but other algorithms may be added 
>>>> in future. If it is still
>>>> 231:???????? required to use one of these algorithms, then they can 
>>>> be re-enabled by setting
>>>> 232:???????? this property to a comma separated list of the 
>>>> algorithm names.</P>
>>> Is it necessary to emphasize that no whitespace is allowed around 
>>> the comma in the property value? Or is it better to modify the 
>>> implementation below to allow whitespaces? I notice that whitespace 
>>> is allowed in some of the other properties. For 
>>> example:https://github.com/openjdk/jdk/blob/de3113b998550021bb502cd6f766036fb8351e7d/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L228
>> Right, probably better to allow whitespace, which seems to be 
>> commonly used in the existing security properties
>>
>>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java 
>>> line 75:
>>>
>>>> 73:???? // A net property which overrides the disabled set above.
>>>> 74:???? private static final String enabledAlgPropName = 
>>>> "http.auth.digest." +
>>>> 75:???????? "reEnabledAlgs";
>>> Why not put the string on one line?
>> I'll try and see if it fits the normal line width
>>
>>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java 
>>> line 670:
>>>
>>>> 668:???????? if (truncate256) {
>>>> 669:???????????? assert digest.length >= 32;
>>>> 670:???????????? start = digest.length - 32;
>>> Does this mean the left half is truncated? My understanding is that 
>>> the right half should be.
>> Okay, I'll double check that. I haven't found any server 
>> implementations of this feature to test with yet,
>>
>> -------------
>>
>> PR:https://git.openjdk.java.net/jdk/pull/7688
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20220307/02ec28f4/attachment-0001.htm>

From erikj at openjdk.java.net  Mon Mar  7 13:44:05 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 7 Mar 2022 13:44:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
Message-ID: <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>

On Sat, 5 Mar 2022 06:49:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?

They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From weijun at openjdk.java.net  Mon Mar  7 14:26:08 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 7 Mar 2022 14:26:08 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <anHW0t-4KnemkkaUn-1lr_ogFC8ozGv26Gdi9QR2pUU=.0f6239bd-5585-4130-8a3a-8269943d92f4@github.com>
 <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
Message-ID: <ekXdqzApKo-b3SJ69CbBvhh40C6WqvwjVvklZ88aJBw=.c5634cfa-df63-45d1-aec7-c199725db2d7@github.com>

On Mon, 7 Mar 2022 11:01:16 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 670:
>> 
>>> 668:         if (truncate256) {
>>> 669:             assert digest.length >= 32;
>>> 670:             start = digest.length - 32;
>> 
>> Does this mean the left half is truncated? My understanding is that the right half should be.
>
> Okay, I'll double check that. I haven't found any server implementations of this feature to test with yet,

2nd test of https://datatracker.ietf.org/doc/html/rfc7616#section-3.9 is on this algorithm, but it requires UTF-8 charset support and a way to provide a predefined cnonce. If it's not worth modifying our implementation to create a regression test, I think at least we can temporarily hack our own JDK and try on it. And I think it's most likely true that this algorithm is using a different initialization vector as Bernd pointed out.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From weijun at openjdk.java.net  Mon Mar  7 14:45:04 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 7 Mar 2022 14:45:04 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <ekXdqzApKo-b3SJ69CbBvhh40C6WqvwjVvklZ88aJBw=.c5634cfa-df63-45d1-aec7-c199725db2d7@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <anHW0t-4KnemkkaUn-1lr_ogFC8ozGv26Gdi9QR2pUU=.0f6239bd-5585-4130-8a3a-8269943d92f4@github.com>
 <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
 <ekXdqzApKo-b3SJ69CbBvhh40C6WqvwjVvklZ88aJBw=.c5634cfa-df63-45d1-aec7-c199725db2d7@github.com>
Message-ID: <ukrw7FFQbUztwc27Dxd-5FtZxcCJdcqx7S75lxPX7MU=.908f751a-893c-4817-9511-c52429c937d2@github.com>

On Mon, 7 Mar 2022 14:22:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Okay, I'll double check that. I haven't found any server implementations of this feature to test with yet,
>
> 2nd test of https://datatracker.ietf.org/doc/html/rfc7616#section-3.9 is on this algorithm, but it requires UTF-8 charset support and a way to provide a predefined cnonce. If it's not worth modifying our implementation to create a regression test, I think at least we can temporarily hack our own JDK and try on it. And I think it's most likely true that this algorithm is using a different initialization vector as Bernd pointed out.

As https://www.rfc-editor.org/errata_search.php?rfc=7616&rec_status=0 shows, that 2nd test in rfc7616 was wrong in the initial version as it used a truncated version of SHA-512. The real SHA-512/256 algorithm should be used.

$ jshell
jshell> import java.security.MessageDigest

jshell> HexFormat.of().formatHex(MessageDigest.getInstance("SHA-512").digest("J\u00e4s\u00f8n Doe:api at example.org".getBytes("UTF-8")))
$2 ==> "488869477bf257147b804c45308cd62ac4e25eb717b12b298c79e62dcea254ec5211a6631b181289b4dd8c14890f38f04bff8a388106dabb900c6984ba592b6a"

jshell> HexFormat.of().formatHex(MessageDigest.getInstance("SHA-512/256").digest("J\u00e4s\u00f8n Doe:api at example.org".getBytes("UTF-8")))
$3 ==> "793263caabb707a56211940d90411ea4a575adeccb7e360aeb624ed06ece9b0b"

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From jwaters at openjdk.java.net  Mon Mar  7 16:24:00 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Mon, 7 Mar 2022 16:24:00 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
 <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>
Message-ID: <WUgibFurfKq3h0sqZ2YDVuSbxl-gxhmgJPnoUPWpeX4=.7af5c5e5-a326-4708-9eb9-d64f41c9af7c@github.com>

On Mon, 7 Mar 2022 13:40:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?
> 
> They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you.

Alright, I can't change the title of the PR, I guess it'll be easier for me to change the issue instead

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From duke at openjdk.java.net  Mon Mar  7 16:37:07 2022
From: duke at openjdk.java.net (zzambers)
Date: Mon, 7 Mar 2022 16:37:07 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v2]
In-Reply-To: <V1YL5fqQGJDv8Ie_92pze5F52zj_mMdxI6YJnW9s9VE=.75831831-d52c-40ba-aa5c-f1b4a2c92ca0@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <j4sqdo5vLlBwWSUNCpQEzns9tlaPY2ORgxEtJ7yhmfA=.d9a984be-82c6-4bfa-8632-56ced31828ab@github.com>
 <V1YL5fqQGJDv8Ie_92pze5F52zj_mMdxI6YJnW9s9VE=.75831831-d52c-40ba-aa5c-f1b4a2c92ca0@github.com>
Message-ID: <aaV94yQvjHRziwGoBRGfgUqzsJl6Wqxgrhvr78ALt-4=.1503e22d-c2aa-4490-9b43-306b186bdc98@github.com>

On Fri, 4 Mar 2022 23:43:30 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> zzambers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyright for SSLSocket.java
>
> There are more changes needed, and should probably be done as part of this issue since we're already in this code anyway.  The current code only talks about shutdownInput/shutdownOutput, but makes no mention of the duplex close(), which is the other way to shutdown the SSLSocket.  It only needs a few words.
> 
> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029167.html
> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html
> 
> These two changes will require a CSR to update the @ apiNote.

@bradfordwetmore Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the process. Is action expected from my side?

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From lancea at openjdk.java.net  Mon Mar  7 16:43:08 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 7 Mar 2022 16:43:08 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

What problem are you having editing the PR header?   You should be able to do so as the author of the PR

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From kcr at openjdk.java.net  Mon Mar  7 16:52:07 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 16:52:07 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
Message-ID: <OlXgsLnUYvaXKuqKPGlg36JcuDUmXp8jC-8P6Y2o35k=.e68e429a-72b7-4828-9ea6-2be0165d2cdf@github.com>

On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> What problem are you having editing the PR header? You should be able to do so as the author of the PR

Exactly. You should see an "Edit" button near the right edge of the PR title. See the attached image:

![PR-title](https://user-images.githubusercontent.com/34689748/157079404-eadbe8be-ae94-41e0-b17b-0d1a8026b9da.png)

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From kcr at openjdk.java.net  Mon Mar  7 16:56:06 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 16:56:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <ya35_llZyJFaqTkVaOv3ybkki4iCaQUTO_PPCw8XaPg=.eb0e2be9-5ed0-4be8-8a14-47f573b6dbfb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

But as the JBS title and PR title now match, this is a moot point.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From kcr at openjdk.java.net  Mon Mar  7 17:18:03 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 17:18:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
 <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>
Message-ID: <gU_j20iocr_5kNAxvBLGmM3fgGRXQdnmguOWyMdIe4E=.d980a805-e168-4a7d-b9d9-a1a09df4b870@github.com>

On Mon, 7 Mar 2022 17:12:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue.

Ah, that explains it then.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From ihse at openjdk.java.net  Mon Mar  7 17:18:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Mar 2022 17:18:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
Message-ID: <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>

On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> What problem are you having editing the PR header?   You should be able to do so as the author of the PR

@LanceAndersen @kevinrushforth TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From darcy at openjdk.java.net  Mon Mar  7 17:43:50 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Mar 2022 17:43:50 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException [v2]
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <me1-5SYfE-dhCm6YgsUcTsES9NXaJUdy2TS-6kq5NmA=.3da0a169-5f9e-4619-94e8-2486704287cc@github.com>

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

Joe Darcy 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:

 - Add regression test.
 - Merge branch 'master' into JDK-8282686
 - JDK-8282686: Add constructors take a cause to SocketException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7705/files
  - new: https://git.openjdk.java.net/jdk/pull/7705/files/e65f9ae5..978b379d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=00-01

  Stats: 8268 lines in 175 files changed: 6072 ins; 1565 del; 631 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7705.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7705/head:pull/7705

PR: https://git.openjdk.java.net/jdk/pull/7705

From darcy at openjdk.java.net  Mon Mar  7 17:55:45 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Mar 2022 17:55:45 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException [v3]
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com>

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Improve test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7705/files
  - new: https://git.openjdk.java.net/jdk/pull/7705/files/978b379d..da863692

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=01-02

  Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7705.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7705/head:pull/7705

PR: https://git.openjdk.java.net/jdk/pull/7705

From darcy at openjdk.java.net  Mon Mar  7 17:55:47 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Mar 2022 17:55:47 GMT
Subject: Integrated: JDK-8282686: Add constructors taking a cause to
 SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <yBSi4gMu54o8DdW3MM6OvlW9f3MrUc_geP-bOnS6KO8=.9f9f94a7-8656-4238-8386-c7888042e8b5@github.com>

On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

This pull request has now been integrated.

Changeset: 1faa5c80
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1faa5c8092f8baec3ca08ed059653876ec46db46
Stats:     102 lines in 7 files changed: 77 ins; 12 del; 13 mod

8282686: Add constructors taking a cause to SocketException

Reviewed-by: alanb, xuelei, lancea, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/7705

From djelinski at openjdk.java.net  Mon Mar  7 17:59:08 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 7 Mar 2022 17:59:08 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments [v7]
In-Reply-To: <ie329T6Er-keCR7sfUYVVfgYRdPILhQN6rU_oW7d3Ns=.c9d27f7d-28f2-4807-9288-a4467d65813c@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
 <ie329T6Er-keCR7sfUYVVfgYRdPILhQN6rU_oW7d3Ns=.c9d27f7d-28f2-4807-9288-a4467d65813c@github.com>
Message-ID: <XgFJBY3lJUz5fNa9ywWoL-omSIk5iEDDZsUABG0gSKU=.f3c20f72-5452-47c2-a257-162cfc9b883d@github.com>

On Mon, 7 Feb 2022 09:14:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Clean up of various issues related to error handling and memory management
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize return value in all cases

Hi!
Would it help with the review if I split this patch into smaller portions? It contains 20-ish independent fixes for memory leaks, invalid free, and incorrect return value handling; I could easily put each of these changes in a separate PR if that helps.

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

PR: https://git.openjdk.java.net/jdk/pull/6090

From wetmore at openjdk.java.net  Mon Mar  7 19:24:04 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 7 Mar 2022 19:24:04 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID: <Vuv-ObjwB70sGV7OQj7-w3NcDErfRXqHwUd4jPxUUHc=.555904fe-763c-4eba-898e-66ab02344501@github.com>

On Mon, 7 Mar 2022 07:52:29 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
> 
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724

src/java.base/share/classes/javax/net/ssl/SSLException.java line 52:

> 50:      */
> 51:     public SSLException(String reason)
> 52:     {

Thanks for changing the style.  I've always hated the extra vertical space.  :)

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From xuelei at openjdk.java.net  Mon Mar  7 19:42:47 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Mar 2022 19:42:47 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID: <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>

> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
> 
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  typo correction

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7722/files
  - new: https://git.openjdk.java.net/jdk/pull/7722/files/20c0c6b6..edb185ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From alanb at openjdk.java.net  Mon Mar  7 19:44:13 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 7 Mar 2022 19:44:13 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException [v3]
In-Reply-To: <7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
 <7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com>
Message-ID: <qNKv9RySagX0mB9oLD3tYuHa7Ja6GcDHnIVg0VKyVRU=.c97d0d0a-6498-4a0a-a4a2-b8d6da6d2dac@github.com>

On Mon, 7 Mar 2022 17:55:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
>> 
>> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve test.

Hmm, this seems to have been integrated without any Reviewer on the final commit. How did that happen?

test/jdk/java/net/SocketException/TestSocketExceptionCtor.java line 32:

> 30: import java.util.Objects;
> 31: 
> 32: public class TestSocketExceptionCtor {

I don't think this is a good name for the test because it tests mores than the constructors. So I think drop the suffix from the name.

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

PR: https://git.openjdk.java.net/jdk/pull/7705

From rhalade at openjdk.java.net  Mon Mar  7 20:06:57 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Mon, 7 Mar 2022 20:06:57 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
Message-ID: <gn3wQFG0zzxnfbSg-Hpuh36_JouXxFcvrNiJC9xC_uM=.6a237f78-6a70-41db-bf7d-8f8d69db761f@github.com>

On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>> 
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo correction

Please consider adding simple tests to cover new APIs, similar to https://github.com/openjdk/jdk/pull/7705/files#diff-28e1041be519b6266b3b92aea29c5d8917c279880da7e5e9823a518196e96ea5

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From rhalade at openjdk.java.net  Mon Mar  7 20:26:56 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Mon, 7 Mar 2022 20:26:56 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
Message-ID: <x-Up7aOV7a0d693vgMyu22n-Uf6YQ7a4rXPKwlbZm6Q=.251413ee-ae24-4b22-883a-2d0cafce5b15@github.com>

On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>> 
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo correction

Update following for SSLPeerUnverifiedException -

https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java#L439

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From wetmore at openjdk.java.net  Mon Mar  7 20:33:01 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 7 Mar 2022 20:33:01 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
Message-ID: <N-hS71X44AcK7Ws9-ZrqByAPPVb4Dd_7YHcxUzoZXxM=.b1d66a49-d04e-4adb-ad5e-f4d59b291149@github.com>

On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>> 
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo correction

src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 158:

> 156:             } catch (GeneralSecurityException gse) {
> 157:                 throw new SSLHandshakeException(
> 158:                         "Could not generate secret", gse);

I can't quite tell given the coloring, but did this get changed into a tab?

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From mullan at openjdk.java.net  Mon Mar  7 20:38:03 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 7 Mar 2022 20:38:03 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <5mHz6hrcfrSlsZOjP7VFi0VhF3k29LBmX2xm8HpGiEI=.b7da60be-6b1e-492d-9100-1e4752d5a2b3@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 514:

> 512:         if (getAuthType() == AuthCacheValue.Type.Server &&
> 513:                 getProtocolScheme().equals("https")) {
> 514:             // HTTPS server authentication can use any algorithm

A more security conscious user may want to disable MD5 digest authentication, even when used over HTTPS, even though the risks are far less than when used over HTTP. Is there a way to do that?

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From wetmore at openjdk.java.net  Mon Mar  7 20:45:05 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 7 Mar 2022 20:45:05 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
Message-ID: <ap9vkHf7ANdhyH1Ns5_zQTtJRUDqMtlCKC3nEEth6MM=.3dbf405b-b62a-4e60-861a-89ca62fe2312@github.com>

On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>> 
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo correction

Didn't see any unit tests for the new methods.  Can approve after they are included.

src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java line 204:

> 202:             } catch (GeneralSecurityException | java.io.IOException e) {
> 203:                 throw new SSLHandshakeException(
> 204:                         "Could not generate ECPublicKey", e);

Nit:  I think combining these lines would be < 80 chars

src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java line 263:

> 261:             fragment = plaintext.fragment;
> 262:             contentType = plaintext.contentType;
> 263:         } catch (BadPaddingException bpe) {

Does the copyright need to get updated?

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From xuelei at openjdk.java.net  Mon Mar  7 20:45:06 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Mar 2022 20:45:06 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <N-hS71X44AcK7Ws9-ZrqByAPPVb4Dd_7YHcxUzoZXxM=.b1d66a49-d04e-4adb-ad5e-f4d59b291149@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
 <N-hS71X44AcK7Ws9-ZrqByAPPVb4Dd_7YHcxUzoZXxM=.b1d66a49-d04e-4adb-ad5e-f4d59b291149@github.com>
Message-ID: <Ns2sbCqijaRwgmeBNbfAPQeS6TUd1nGkxxUunP9sEIQ=.1fd562f8-8da4-4930-a564-117bc5d78b26@github.com>

On Mon, 7 Mar 2022 20:30:07 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo correction
>
> src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 158:
> 
>> 156:             } catch (GeneralSecurityException gse) {
>> 157:                 throw new SSLHandshakeException(
>> 158:                         "Could not generate secret", gse);
> 
> I can't quite tell given the coloring, but did this get changed into a tab?

Yes, I added 4 more whitespaces in line 158.

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From wetmore at openjdk.java.net  Mon Mar  7 20:45:06 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 7 Mar 2022 20:45:06 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <Ns2sbCqijaRwgmeBNbfAPQeS6TUd1nGkxxUunP9sEIQ=.1fd562f8-8da4-4930-a564-117bc5d78b26@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
 <N-hS71X44AcK7Ws9-ZrqByAPPVb4Dd_7YHcxUzoZXxM=.b1d66a49-d04e-4adb-ad5e-f4d59b291149@github.com>
 <Ns2sbCqijaRwgmeBNbfAPQeS6TUd1nGkxxUunP9sEIQ=.1fd562f8-8da4-4930-a564-117bc5d78b26@github.com>
Message-ID: <IlkPYopfZv6yDbcz2ztyrT1pGyHc3ntrcHdogbvonCc=.865dabf5-71b4-49c3-8e13-a60a6ffd78bb@github.com>

On Mon, 7 Mar 2022 20:39:44 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 158:
>> 
>>> 156:             } catch (GeneralSecurityException gse) {
>>> 157:                 throw new SSLHandshakeException(
>>> 158:                         "Could not generate secret", gse);
>> 
>> I can't quite tell given the coloring, but did this get changed into a tab?
>
> Yes, I added 4 more whitespaces in line 158.

Ah, missed that.  Good to be consistent.

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From xuelei at openjdk.java.net  Mon Mar  7 20:54:58 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Mar 2022 20:54:58 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
Message-ID: <c_yWB-6Kf7G2WQbJLrbe2-emlEVJ8Chbi88RCRGHkNw=.6352a6c5-e243-4b1e-8e61-6b2da8b2073f@github.com>

On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>> 
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo correction

>

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From xuelei at openjdk.java.net  Mon Mar  7 20:54:59 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Mar 2022 20:54:59 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <x-Up7aOV7a0d693vgMyu22n-Uf6YQ7a4rXPKwlbZm6Q=.251413ee-ae24-4b22-883a-2d0cafce5b15@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
 <x-Up7aOV7a0d693vgMyu22n-Uf6YQ7a4rXPKwlbZm6Q=.251413ee-ae24-4b22-883a-2d0cafce5b15@github.com>
Message-ID: <_k7ZQ-0FCYrNXalYTh9tyeZV-NF3868N4m7A0FKEY2I=.f6441cb7-3033-4a82-bfd7-2faa62fc4874@github.com>

On Mon, 7 Mar 2022 20:24:08 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Update following for SSLPeerUnverifiedException -
> 
> https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java#L439

Hm, I will check more usage out of the JSSE implementation code.  Thank you!

> Please consider adding simple tests to cover new APIs, similar to https://github.com/openjdk/jdk/pull/7705/files#diff-28e1041be519b6266b3b92aea29c5d8917c279880da7e5e9823a518196e96ea5

Thank you for the reference.  I will add some test cases.

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From xuelei at openjdk.java.net  Mon Mar  7 20:54:59 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 7 Mar 2022 20:54:59 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <ap9vkHf7ANdhyH1Ns5_zQTtJRUDqMtlCKC3nEEth6MM=.3dbf405b-b62a-4e60-861a-89ca62fe2312@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
 <ap9vkHf7ANdhyH1Ns5_zQTtJRUDqMtlCKC3nEEth6MM=.3dbf405b-b62a-4e60-861a-89ca62fe2312@github.com>
Message-ID: <X1I8CgSMBdDsi02XXomQRw0xrHCTkCCojklcXI24MBQ=.0fe6e2fd-265c-4e58-915d-e8be672a93f7@github.com>

On Mon, 7 Mar 2022 20:36:41 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo correction
>
> src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java line 263:
> 
>> 261:             fragment = plaintext.fragment;
>> 262:             contentType = plaintext.contentType;
>> 263:         } catch (BadPaddingException bpe) {
> 
> Does the copyright need to get updated?

Oops, I missed this file.

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From wetmore at openjdk.java.net  Mon Mar  7 21:04:00 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 7 Mar 2022 21:04:00 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v2]
In-Reply-To: <aaV94yQvjHRziwGoBRGfgUqzsJl6Wqxgrhvr78ALt-4=.1503e22d-c2aa-4490-9b43-306b186bdc98@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <j4sqdo5vLlBwWSUNCpQEzns9tlaPY2ORgxEtJ7yhmfA=.d9a984be-82c6-4bfa-8632-56ced31828ab@github.com>
 <V1YL5fqQGJDv8Ie_92pze5F52zj_mMdxI6YJnW9s9VE=.75831831-d52c-40ba-aa5c-f1b4a2c92ca0@github.com>
 <aaV94yQvjHRziwGoBRGfgUqzsJl6Wqxgrhvr78ALt-4=.1503e22d-c2aa-4490-9b43-306b186bdc98@github.com>
Message-ID: <NmGt4etntWHORR90TXqpODCcTAVHlvf_58jcp5gFbBE=.dc5a0e75-d574-4e21-9044-d79f9fb5ee3b@github.com>

On Mon, 7 Mar 2022 16:34:08 GMT, zzambers <duke at openjdk.java.net> wrote:

> Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the
 process. Is action expected from my side?

One of us needs to get the CSR approved.  Why don't you pull the changes described in:

https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html

Assuming you are ok with the updated wording, I can create the CSR and submit.  Once that it approved, then we can get this PR approved and you can integrate. 

Are you at contributor status?

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From duke at openjdk.java.net  Mon Mar  7 21:37:05 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Mon, 7 Mar 2022 21:37:05 GMT
Subject: Integrated: 8282657: Code cleanup: removing double semicolons at the
 end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <IOsP6dA-9UbtLKUQwfdQE9Z6Lc6qO2iUIy_8Ywsk4Z0=.cbc4836e-3973-4cb3-bdb6-c413368ce9f5@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

This pull request has now been integrated.

Changeset: ccad3923
Author:    Matteo Baccan <matteo.baccan at gmail.com>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ccad39237ab860c5c5579537f740177e3f1adcc9
Stats:     93 lines in 82 files changed: 0 ins; 0 del; 93 mod

8282657: Code cleanup: removing double semicolons at the end of lines

Reviewed-by: lancea, rriggs, ihse, prr, iris, wetmore, darcy, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From xuelei at openjdk.java.net  Tue Mar  8 05:47:54 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 8 Mar 2022 05:47:54 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v3]
In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID: <bisI2XN9OhP-WhFgrkXH5v9-Eh6yLCBDNb7svifvgP0=.bfd77e40-199d-45bc-b6e5-3b9fd7b52ebf@github.com>

> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
> 
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  update more usage and add test cases

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7722/files
  - new: https://git.openjdk.java.net/jdk/pull/7722/files/edb185ec..628605e6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=01-02

  Stats: 216 lines in 10 files changed: 200 ins; 5 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7722/head:pull/7722

PR: https://git.openjdk.java.net/jdk/pull/7722

From xuelei at openjdk.java.net  Tue Mar  8 05:55:06 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 8 Mar 2022 05:55:06 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <ap9vkHf7ANdhyH1Ns5_zQTtJRUDqMtlCKC3nEEth6MM=.3dbf405b-b62a-4e60-861a-89ca62fe2312@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
 <ap9vkHf7ANdhyH1Ns5_zQTtJRUDqMtlCKC3nEEth6MM=.3dbf405b-b62a-4e60-861a-89ca62fe2312@github.com>
Message-ID: <R1XfXRGllZv_MfJC9AOOgejalScEK6a4zhOOV70PWgM=.e8c32133-07fc-4406-9661-838c27a458f3@github.com>

On Mon, 7 Mar 2022 20:34:02 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo correction
>
> src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java line 204:
> 
>> 202:             } catch (GeneralSecurityException | java.io.IOException e) {
>> 203:                 throw new SSLHandshakeException(
>> 204:                         "Could not generate ECPublicKey", e);
> 
> Nit:  I think combining these lines would be < 80 chars

The exception name is too long to have in one line.  There are 83 characters in total if combining line 203 and 204.  3 characters exceeding 80 chars per line limit is not easy to tell with eyes.

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From xuelei at openjdk.java.net  Tue Mar  8 06:02:58 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 8 Mar 2022 06:02:58 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v4]
In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID: <M4ZV9N7eDBXMstmU0ZgJO7YvgW93pKT57U7per_TtQ4=.6a37f50a-1f82-4932-9399-5403c8d4321e@github.com>

> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
> 
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  update usage in test template

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7722/files
  - new: https://git.openjdk.java.net/jdk/pull/7722/files/628605e6..37953310

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From xuelei at openjdk.java.net  Tue Mar  8 08:02:16 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 8 Mar 2022 08:02:16 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v5]
In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID: <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>

> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
> 
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  more test case udpate

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7722/files
  - new: https://git.openjdk.java.net/jdk/pull/7722/files/37953310..61cc7934

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From duke at openjdk.java.net  Tue Mar  8 14:21:19 2022
From: duke at openjdk.java.net (zzambers)
Date: Tue, 8 Mar 2022 14:21:19 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v3]
In-Reply-To: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
Message-ID: <J2BZHd3AsQI1ON4aRPYsWvu-8GD5PQnrYfTBYBwK99g=.d66b4a6a-f64c-45ae-b1c3-03f690b6008d@github.com>

> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326

zzambers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  javax/net/ssl/SSLSocket: Fixed API Note in javadoc

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

Changes: https://git.openjdk.java.net/jdk/pull/7648/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=02
  Stats: 13 lines in 1 file changed: 2 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7648.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7648/head:pull/7648

PR: https://git.openjdk.java.net/jdk/pull/7648

From duke at openjdk.java.net  Tue Mar  8 14:28:05 2022
From: duke at openjdk.java.net (zzambers)
Date: Tue, 8 Mar 2022 14:28:05 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v2]
In-Reply-To: <NmGt4etntWHORR90TXqpODCcTAVHlvf_58jcp5gFbBE=.dc5a0e75-d574-4e21-9044-d79f9fb5ee3b@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <j4sqdo5vLlBwWSUNCpQEzns9tlaPY2ORgxEtJ7yhmfA=.d9a984be-82c6-4bfa-8632-56ced31828ab@github.com>
 <V1YL5fqQGJDv8Ie_92pze5F52zj_mMdxI6YJnW9s9VE=.75831831-d52c-40ba-aa5c-f1b4a2c92ca0@github.com>
 <aaV94yQvjHRziwGoBRGfgUqzsJl6Wqxgrhvr78ALt-4=.1503e22d-c2aa-4490-9b43-306b186bdc98@github.com>
 <NmGt4etntWHORR90TXqpODCcTAVHlvf_58jcp5gFbBE=.dc5a0e75-d574-4e21-9044-d79f9fb5ee3b@github.com>
Message-ID: <i4tam_xtGnYjQjEr7Dw0oyLhOg8wPI8UTfZlWC0k_4E=.46365b1a-af19-4674-a102-ef7987be4aa4@github.com>

On Mon, 7 Mar 2022 21:01:12 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> @bradfordwetmore Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the process. Is action expected from my side?
>
>> Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the
>  process. Is action expected from my side?
> 
> One of us needs to get the CSR approved.  Why don't you pull the changes described in:
> 
> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html
> 
> Assuming you are ok with the updated wording, I can create the CSR and submit.  Once that it approved, then we can get this PR approved and you can integrate. 
> 
> Are you at contributor status?

@bradfordwetmore I have updated this PR with your patch. I am covered by OCA.

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From rriggs at openjdk.java.net  Tue Mar  8 14:52:02 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 8 Mar 2022 14:52:02 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v2]
In-Reply-To: <R1XfXRGllZv_MfJC9AOOgejalScEK6a4zhOOV70PWgM=.e8c32133-07fc-4406-9661-838c27a458f3@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <f1n9up5HO_zfYNyh9ZTeZC7oBXmeSQSfW5EZOP1vLB0=.e6aacd56-c941-49dd-bf35-98d27f87ea98@github.com>
 <ap9vkHf7ANdhyH1Ns5_zQTtJRUDqMtlCKC3nEEth6MM=.3dbf405b-b62a-4e60-861a-89ca62fe2312@github.com>
 <R1XfXRGllZv_MfJC9AOOgejalScEK6a4zhOOV70PWgM=.e8c32133-07fc-4406-9661-838c27a458f3@github.com>
Message-ID: <BoWrQv6kon7lBfHWXig_9Lzq9FPIOxnKuXp-JzLv8O4=.1e0779d4-ac4c-4d20-8533-8545ddab30df@github.com>

On Tue, 8 Mar 2022 05:51:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java line 204:
>> 
>>> 202:             } catch (GeneralSecurityException | java.io.IOException e) {
>>> 203:                 throw new SSLHandshakeException(
>>> 204:                         "Could not generate ECPublicKey", e);
>> 
>> Nit:  I think combining these lines would be < 80 chars
>
> The exception name is too long to have in one line.  There are 83 characters in total if combining line 203 and 204.  3 characters exceeding 80 chars per line limit is not easy to tell with eyes.

The 80 character recommendation isn't a hard limit, I favor readability in the 80-100 char range.

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From duke at openjdk.java.net  Tue Mar  8 15:03:57 2022
From: duke at openjdk.java.net (zzambers)
Date: Tue, 8 Mar 2022 15:03:57 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v3]
In-Reply-To: <J2BZHd3AsQI1ON4aRPYsWvu-8GD5PQnrYfTBYBwK99g=.d66b4a6a-f64c-45ae-b1c3-03f690b6008d@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <J2BZHd3AsQI1ON4aRPYsWvu-8GD5PQnrYfTBYBwK99g=.d66b4a6a-f64c-45ae-b1c3-03f690b6008d@github.com>
Message-ID: <DTFmVks49n0iqqyLeVq26wMLxBCrqvbVTrYzi2C4Vxc=.558651a4-9117-40fa-bccb-abf63f1ccd03@github.com>

On Tue, 8 Mar 2022 14:21:19 GMT, zzambers <duke at openjdk.java.net> wrote:

>> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
>> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
>
> zzambers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   javax/net/ssl/SSLSocket: Fixed API Note in javadoc

But I am not a Commiter (I need sponsor).

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From duke at openjdk.java.net  Tue Mar  8 15:03:57 2022
From: duke at openjdk.java.net (zzambers)
Date: Tue, 8 Mar 2022 15:03:57 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v4]
In-Reply-To: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
Message-ID: <scn9daKYtSwX95QlW1vDh7c1e3bJZAimgsaN6w80l0w=.e3934b85-32a7-4884-8f19-27e8b6b2b416@github.com>

> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326

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

  small fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7648/files
  - new: https://git.openjdk.java.net/jdk/pull/7648/files/ddd59a9e..38d649e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From duke at openjdk.java.net  Tue Mar  8 15:25:57 2022
From: duke at openjdk.java.net (zzambers)
Date: Tue, 8 Mar 2022 15:25:57 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v2]
In-Reply-To: <NmGt4etntWHORR90TXqpODCcTAVHlvf_58jcp5gFbBE=.dc5a0e75-d574-4e21-9044-d79f9fb5ee3b@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <j4sqdo5vLlBwWSUNCpQEzns9tlaPY2ORgxEtJ7yhmfA=.d9a984be-82c6-4bfa-8632-56ced31828ab@github.com>
 <V1YL5fqQGJDv8Ie_92pze5F52zj_mMdxI6YJnW9s9VE=.75831831-d52c-40ba-aa5c-f1b4a2c92ca0@github.com>
 <aaV94yQvjHRziwGoBRGfgUqzsJl6Wqxgrhvr78ALt-4=.1503e22d-c2aa-4490-9b43-306b186bdc98@github.com>
 <NmGt4etntWHORR90TXqpODCcTAVHlvf_58jcp5gFbBE=.dc5a0e75-d574-4e21-9044-d79f9fb5ee3b@github.com>
Message-ID: <RTMIZVUctVVu5k-Pij3U7jtFsLLQIX9a_8qfNwEqD54=.91e76e3f-94d4-4308-8527-3c6e6871475c@github.com>

On Mon, 7 Mar 2022 21:01:12 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> @bradfordwetmore Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the process. Is action expected from my side?
>
>> Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the
>  process. Is action expected from my side?
> 
> One of us needs to get the CSR approved.  Why don't you pull the changes described in:
> 
> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html
> 
> Assuming you are ok with the updated wording, I can create the CSR and submit.  Once that it approved, then we can get this PR approved and you can integrate. 
> 
> Are you at contributor status?

@bradfordwetmore Your changes look good to me. When it comes to wording, I'll let that to native english speaker(s) to judge :) (As I am not native english speaker myself).  I built docs locally and result looks good (also links work), there was just one problem with brace, but I have fixed that.

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From msheppar at openjdk.java.net  Tue Mar  8 15:42:02 2022
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Tue, 8 Mar 2022 15:42:02 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments [v7]
In-Reply-To: <ie329T6Er-keCR7sfUYVVfgYRdPILhQN6rU_oW7d3Ns=.c9d27f7d-28f2-4807-9288-a4467d65813c@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
 <ie329T6Er-keCR7sfUYVVfgYRdPILhQN6rU_oW7d3Ns=.c9d27f7d-28f2-4807-9288-a4467d65813c@github.com>
Message-ID: <djvtgmrkjIEomtS3vqrqrqPQ7x-3NaMlr3n1c2bfN0E=.499bc4bb-3d10-4f00-b613-7d4db173e824@github.com>

On Mon, 7 Feb 2022 09:14:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Clean up of various issues related to error handling and memory management
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize return value in all cases

Marked as reviewed by msheppar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/6090

From dfuchs at openjdk.java.net  Tue Mar  8 16:14:16 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 8 Mar 2022 16:14:16 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments [v7]
In-Reply-To: <ie329T6Er-keCR7sfUYVVfgYRdPILhQN6rU_oW7d3Ns=.c9d27f7d-28f2-4807-9288-a4467d65813c@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
 <ie329T6Er-keCR7sfUYVVfgYRdPILhQN6rU_oW7d3Ns=.c9d27f7d-28f2-4807-9288-a4467d65813c@github.com>
Message-ID: <DMwktTwxCC8FksXUQRP1muxEaFQUQsZZTXDMPvxxj60=.76e58a09-c405-4ccb-8517-f11900516c45@github.com>

On Mon, 7 Feb 2022 09:14:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Clean up of various issues related to error handling and memory management
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize return value in all cases

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/6090

From djelinski at openjdk.java.net  Tue Mar  8 16:19:09 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 8 Mar 2022 16:19:09 GMT
Subject: Integrated: 8275640 (win) java.net.NetworkInterface issues with
 IPv6-only environments
In-Reply-To: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
Message-ID: <6j-OtMvostwj0C69T0c6KberCfRswvwCtDWUnKmmtVs=.b12ae3d7-6319-4c60-8196-a9fba436231b@github.com>

On Sat, 23 Oct 2021 10:26:34 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Clean up of various issues related to error handling and memory management

This pull request has now been integrated.

Changeset: 2549e550
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2549e5503806447733572643603af9a2bf4b52e5
Stats:     68 lines in 2 files changed: 35 ins; 20 del; 13 mod

8275640: (win) java.net.NetworkInterface issues with IPv6-only environments

Reviewed-by: msheppar, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/6090

From mullan at openjdk.java.net  Tue Mar  8 16:46:13 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 8 Mar 2022 16:46:13 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v19]
In-Reply-To: <V6Ww8N15wiAjzdoYuLZWkJX3EzgMZKXr0X6mx5wpDwc=.26adf6c5-8668-4ef0-815e-c5772b095fe8@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <V6Ww8N15wiAjzdoYuLZWkJX3EzgMZKXr0X6mx5wpDwc=.26adf6c5-8668-4ef0-815e-c5772b095fe8@github.com>
Message-ID: <KfXXHbzX_jw2cNXK1c4aLjpDl5jgTqSZiSERiFj4vGE=.3ee7fd74-d278-47a1-b143-f2abc128b09b@github.com>

On Sun, 6 Mar 2022 05:40:59 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494
>> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test for DTLS

Changes requested by mullan (Reviewer).

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 501:

> 499: 
> 500:             // Note that if the System Property value is not defined (JDK
> 501:             // default value) or empty, the provider-specific default is used.

I think you can remove this comment as it is repeated on lines 507-508 (and makes more sense there).

src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 564:

> 562:                 String[] signatureSchemes) {
> 563: 
> 564:         if (signatureSchemes == null ||  signatureSchemes.length == 0) {

Nit: remove extra space after `||`.

src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 576:

> 574:                     SSLLogger.finest(
> 575:                             "Ignore the signature algorithm (" + ss
> 576:                           + "), unsupported or unavailable");

Should this message be more consistent with the message in `getCustomizedSignatureScheme`?: "The current installed providers do not support signature scheme: " + schemeName

test/jdk/javax/net/ssl/DTLS/DTLSSignatureSchemes.java line 125:

> 123:             testCase.runTest(testCase);
> 124:             if (exceptionExpected) {
> 125:                 throw new RuntimeException("Unexpected success!");

The catch block on line 127 will end up catching this exception and swallowing it, and the test will incorrectly pass.

test/jdk/javax/net/ssl/SSLParameters/SignatureSchemes.java line 81:

> 79:             super.runClientApplication(sslSocket);
> 80:             if (exceptionExpected) {
> 81:                 throw new RuntimeException("Unexpected success!");

The catch block on line 83 will end up catching this exception and swallowing it, and the test will incorrectly pass.

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

PR: https://git.openjdk.java.net/jdk/pull/7252

From wetmore at openjdk.java.net  Tue Mar  8 22:15:06 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 8 Mar 2022 22:15:06 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v2]
In-Reply-To: <RTMIZVUctVVu5k-Pij3U7jtFsLLQIX9a_8qfNwEqD54=.91e76e3f-94d4-4308-8527-3c6e6871475c@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <j4sqdo5vLlBwWSUNCpQEzns9tlaPY2ORgxEtJ7yhmfA=.d9a984be-82c6-4bfa-8632-56ced31828ab@github.com>
 <V1YL5fqQGJDv8Ie_92pze5F52zj_mMdxI6YJnW9s9VE=.75831831-d52c-40ba-aa5c-f1b4a2c92ca0@github.com>
 <aaV94yQvjHRziwGoBRGfgUqzsJl6Wqxgrhvr78ALt-4=.1503e22d-c2aa-4490-9b43-306b186bdc98@github.com>
 <NmGt4etntWHORR90TXqpODCcTAVHlvf_58jcp5gFbBE=.dc5a0e75-d574-4e21-9044-d79f9fb5ee3b@github.com>
 <RTMIZVUctVVu5k-Pij3U7jtFsLLQIX9a_8qfNwEqD54=.91e76e3f-94d4-4308-8527-3c6e6871475c@github.com>
Message-ID: <ZUJ5wfTkp5aKMaFHit2zPJ5__dfTN1FtobOTbgZ0C3g=.8311ab27-79bf-451a-a12a-e5075fd04008@github.com>

On Tue, 8 Mar 2022 15:23:13 GMT, zzambers <duke at openjdk.java.net> wrote:

>>> Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the
>>  process. Is action expected from my side?
>> 
>> One of us needs to get the CSR approved.  Why don't you pull the changes described in:
>> 
>> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html
>> 
>> Assuming you are ok with the updated wording, I can create the CSR and submit.  Once that it approved, then we can get this PR approved and you can integrate. 
>> 
>> Are you at contributor status?
>
> @bradfordwetmore Your changes look good to me. When it comes to wording, I'll let that to native english speaker(s) to judge :) (As I am not native english speaker myself).  I built docs locally and result looks good (also links work), there was just one problem with brace, but I have fixed that.

@zzambers Thanks for catching the two little issues with the closing brackets/missing space.

CSR has been finalized, just need to wait for approval.

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From wetmore at openjdk.java.net  Tue Mar  8 22:15:05 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 8 Mar 2022 22:15:05 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v4]
In-Reply-To: <scn9daKYtSwX95QlW1vDh7c1e3bJZAimgsaN6w80l0w=.e3934b85-32a7-4884-8f19-27e8b6b2b416@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <scn9daKYtSwX95QlW1vDh7c1e3bJZAimgsaN6w80l0w=.e3934b85-32a7-4884-8f19-27e8b6b2b416@github.com>
Message-ID: <iUkBEwOiWOerFd78r0e6fqpWFzY1Zb9kogoB_i58Q2g=.2db0b7bf-8605-4b1a-852c-414ea512a5ab@github.com>

On Tue, 8 Mar 2022 15:03:57 GMT, zzambers <duke at openjdk.java.net> wrote:

>> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
>> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small fixes

LGTM.  I can sponsor after CSR approvals granted.  Please hold off on integrating until then.

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7648

From xuelei at openjdk.java.net  Wed Mar  9 08:25:48 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 9 Mar 2022 08:25:48 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v20]
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <EmTNtwmQwdJQud-Ot22G4Lo3NuAXmZMWxiRhyMYLyGg=.22aafb32-9c00-409f-98c5-3d22927a082d@github.com>

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494
> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  correct test case issues and more

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7252/files
  - new: https://git.openjdk.java.net/jdk/pull/7252/files/ca006ee0..f1611238

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=18-19

  Stats: 21 lines in 4 files changed: 12 ins; 8 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7252.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7252/head:pull/7252

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Wed Mar  9 08:25:50 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 9 Mar 2022 08:25:50 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v19]
In-Reply-To: <KfXXHbzX_jw2cNXK1c4aLjpDl5jgTqSZiSERiFj4vGE=.3ee7fd74-d278-47a1-b143-f2abc128b09b@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <V6Ww8N15wiAjzdoYuLZWkJX3EzgMZKXr0X6mx5wpDwc=.26adf6c5-8668-4ef0-815e-c5772b095fe8@github.com>
 <KfXXHbzX_jw2cNXK1c4aLjpDl5jgTqSZiSERiFj4vGE=.3ee7fd74-d278-47a1-b143-f2abc128b09b@github.com>
Message-ID: <QjvQkfU1jOPFLePEbbWEjkHuJ-pnfCw-6b-3eLX3rFQ=.25b5d752-e881-477d-8141-65b6f70a76f2@github.com>

On Tue, 8 Mar 2022 16:13:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test for DTLS
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 501:
> 
>> 499: 
>> 500:             // Note that if the System Property value is not defined (JDK
>> 501:             // default value) or empty, the provider-specific default is used.
> 
> I think you can remove this comment as it is repeated on lines 507-508 (and makes more sense there).

I agreed.

> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 564:
> 
>> 562:                 String[] signatureSchemes) {
>> 563: 
>> 564:         if (signatureSchemes == null ||  signatureSchemes.length == 0) {
> 
> Nit: remove extra space after `||`.

Thanks for the catch!

> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 576:
> 
>> 574:                     SSLLogger.finest(
>> 575:                             "Ignore the signature algorithm (" + ss
>> 576:                           + "), unsupported or unavailable");
> 
> Should this message be more consistent with the message in `getCustomizedSignatureScheme`?: "The current installed providers do not support signature scheme: " + schemeName

The usage of the method is a little bit different.  This method is mainly used for selecting a few from many signature schemes, and it is usually log with "ignore ..." for those does not match but with high preference.  See also the caller method, getSupportedAlgorithms(), between lines 389-405.

> test/jdk/javax/net/ssl/DTLS/DTLSSignatureSchemes.java line 125:
> 
>> 123:             testCase.runTest(testCase);
>> 124:             if (exceptionExpected) {
>> 125:                 throw new RuntimeException("Unexpected success!");
> 
> The catch block on line 127 will end up catching this exception and swallowing it, and the test will incorrectly pass.

Good catch!

> test/jdk/javax/net/ssl/SSLParameters/SignatureSchemes.java line 81:
> 
>> 79:             super.runClientApplication(sslSocket);
>> 80:             if (exceptionExpected) {
>> 81:                 throw new RuntimeException("Unexpected success!");
> 
> The catch block on line 83 will end up catching this exception and swallowing it, and the test will incorrectly pass.

Good catch!

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

PR: https://git.openjdk.java.net/jdk/pull/7252

From jpai at openjdk.java.net  Wed Mar  9 11:31:08 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 9 Mar 2022 11:31:08 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task
In-Reply-To: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
Message-ID: <vRO5bHf8ySbqvm_gVP4LkeurfRFkXipuYf2fos-eCvc=.7753acc6-62c2-45a7-89f9-fa91a30eafd7@github.com>

On Mon, 24 Jan 2022 14:25:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> These changes make sure that pending requests are terminated if the selector manager thread exits due to exceptions.
> This includes:
>    1. completing CompletableFutures that were returned to the caller code
>    2. cancelling requests that are in flight
>    3. calling onError on BodySubscribers that may not have been completed
> Note that step 3 is necessary as certain CompletableFutures, such as those returned by `BodySubscribers.ofInputStream`, complete immediately, the operation being eventually completed when the last bite of the response is read. Completing a completable future that is already completed has no effect, this case is handled by completing the BodySubscriber too.

Hello Daniel, I couldn't fully finish the review, but added my initial comments/questions.

src/java.net.http/share/classes/jdk/internal/net/http/Http1AsyncReceiver.java line 501:

> 499:             debug.log("recorded " + t + "\n\t delegate: " + delegate
> 500:                       + "\n\t queue.isEmpty: " + queue.isEmpty()
> 501:                       + " stopRequested: " + stopRequested, ex);

Should this also be preceded with a `\n\t ` to be consistent with the rest of this log message?

src/java.net.http/share/classes/jdk/internal/net/http/Http1AsyncReceiver.java line 501:

> 499:             debug.log("recorded " + t + "\n\t delegate: " + delegate
> 500:                       + "\n\t queue.isEmpty: " + queue.isEmpty()
> 501:                       + " stopRequested: " + stopRequested, ex);

Should this also be preceded with a `\n\t ` to be consistent with the rest of this log message?

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 366:

> 364:                         refCountTracker.tryRelease();
> 365:                     }
> 366:                 });

I see that later in this code there's another `finally` block where we have now added a `tryRelease` call which first checks the `acquired` flag. A couple of questions:
1. Should this above line too first check the `acquire` flag?
2. Should we reset the `acquire` local variable once we `tryRelease` here so as to prevent another `tryRelease` in the other `finally`  block? A short glance at the implementation of `tryRelease` suggests that multiple `tryRelease()` with a single `acquire()` won't cause a problem in its state but it does end up logging some messages, which perhaps could be avoided.

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 366:

> 364:                         refCountTracker.tryRelease();
> 365:                     }
> 366:                 });

I see that later in this code there's another `finally` block where we have now added a `tryRelease` call which first checks the `acquired` flag. A couple of questions:
1. Should this above line too first check the `acquire` flag?
2. Should we reset the `acquire` local variable once we `tryRelease` here so as to prevent another `tryRelease` in the other `finally`  block? A short glance at the implementation of `tryRelease` suggests that multiple `tryRelease()` with a single `acquire()` won't cause a problem in its state but it does end up logging some messages, which perhaps could be avoided.

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 374:

> 372:                     cf.completeExceptionally(t);
> 373:                 } finally {
> 374:                     if (acquired) refCountTracker.tryRelease();

I see that before this change, we never did a `tryRelease` in this finally block. Was that a separate bug in itself and something that is being fixed as part of this PR?

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 374:

> 372:                     cf.completeExceptionally(t);
> 373:                 } finally {
> 374:                     if (acquired) refCountTracker.tryRelease();

I see that before this change, we never did a `tryRelease` in this finally block. Was that a separate bug in itself and something that is being fixed as part of this PR?

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 647:

> 645:             if (t instanceof EOFException && parser != null &&
> 646:                     parser instanceof UnknownLengthBodyParser) {
> 647:                 ((UnknownLengthBodyParser)parser).complete();

A minor note - while we are it, perhaps the new `instanceof` feature can be used here to avoid this cast?

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 647:

> 645:             if (t instanceof EOFException && parser != null &&
> 646:                     parser instanceof UnknownLengthBodyParser) {
> 647:                 ((UnknownLengthBodyParser)parser).complete();

A minor note - while we are it, perhaps the new `instanceof` feature can be used here to avoid this cast?

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 728:

> 726:                 } else {
> 727:                     if (debug.on()) {
> 728:                         debug.log("no parser");

Should we perhaps log the error message (`Throwable::getMessage`) to provide some kind of hints in the logs when this message is logged? Perhaps `Ignoring error since no parser available: + error.getMessage()`?

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 728:

> 726:                 } else {
> 727:                     if (debug.on()) {
> 728:                         debug.log("no parser");

Should we perhaps log the error message (`Throwable::getMessage`) to provide some kind of hints in the logs when this message is logged? Perhaps `Ignoring error since no parser available: + error.getMessage()`?

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 179:

> 177:             } catch (Throwable t) {
> 178:                 errorHandler.accept(command, t);
> 179:                 ASYNC_POOL.execute(command);

Does this mean that we will now attempt to use an `ASYNC_POOL` even if a had supplied an `Executor`? The `CompletableFuture#defaultExecutor` which is what the `ASYNC_POOL` represents states:

Returns the default Executor used for async methods that do not specify an Executor.

which would now contradict with this code. With the error handler logic in place (one line above), do you think we should just give up on running the `command` instead of passing to the default executor?

Furthermore, if we do decide to use the default executor in cases like this, is that something that all implementations of the `HttpClient` are expected to do (i.e. would it be a specification) or is this more an implementation detail.

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 179:

> 177:             } catch (Throwable t) {
> 178:                 errorHandler.accept(command, t);
> 179:                 ASYNC_POOL.execute(command);

Does this mean that we will now attempt to use an `ASYNC_POOL` even if a had supplied an `Executor`? The `CompletableFuture#defaultExecutor` which is what the `ASYNC_POOL` represents states:

Returns the default Executor used for async methods that do not specify an Executor.

which would now contradict with this code. With the error handler logic in place (one line above), do you think we should just give up on running the `command` instead of passing to the default executor?

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 199:

> 197:     // the selector manager thread exists abnormally.
> 198:     // The request, its id, and its completable future, are stored in a record-like
> 199:     // PendingRequest object added to the pending requests set (pendingRequests).

I'm not too familiar with the HttpClient code yet. Before this change, was there ever a place where we would end up holding onto the request instances in memory and prevent them from being garbage collected? Would this change cause unintentional resource constraints in a regular/good scenario (where the `SelectorManager` thread hasn't exited abnormally and is still alive) or in cases where HTTP responses are slow to come back from servers?

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 199:

> 197:     // the selector manager thread exists abnormally.
> 198:     // The request, its id, and its completable future, are stored in a record-like
> 199:     // PendingRequest object added to the pending requests set (pendingRequests).

I'm not too familiar with the HttpClient code yet. Before this change, was there ever a place where we would end up holding onto the request instances in memory and prevent them from being garbage collected? Would this change cause unintentional resource constraints in a regular/good scenario (where the `SelectorManager` thread hasn't exited abnormally and is still alive) or in cases where HTTP responses are slow to come back from servers?

Perhaps I shouldn't worry about it, since maybe in a regular case, the requests that we are caching here will all be alive (from a GC point of view) even if this caching isn't involved?

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 302:

> 300:             var msg = reason instanceof RejectedExecutionException
> 301:                     ? reason.getClass() : reason;
> 302:             client.debug.log("aborting pending requests due to: %s", msg);

Any reason why we are using a different log message for `RejectedExecutionException`? Would it instead be useful to let the underlying `message` from the `RejectedExecutionException` be logged too just like we are doing for other exception types here?

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 302:

> 300:             var msg = reason instanceof RejectedExecutionException
> 301:                     ? reason.getClass() : reason;
> 302:             client.debug.log("aborting pending requests due to: %s", msg);

Any reason why we are using a different log message for `RejectedExecutionException`? Would it instead be useful to let the underlying `message` from the `RejectedExecutionException` be logged too just like we are doing for other exception types here?

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 308:

> 306:         while (!pendingRequests.isEmpty()) {
> 307:             var pendings = pendingRequests.iterator();
> 308:             while (pendings.hasNext()) {

Would there be a case where while we are aborting these current pending requests, some user code does a  `sendAsync` and we end up add a new pending request to the `Set`? Would we then end up holding those new requests in the `Set` never to be cleared again because, I guess, `abortPendingRequests` won't be called again?

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 308:

> 306:         while (!pendingRequests.isEmpty()) {
> 307:             var pendings = pendingRequests.iterator();
> 308:             while (pendings.hasNext()) {

Would there be a case where while we are aborting these current pending requests, some user code does a  `sendAsync` and we end up add a new pending request to the `Set`? Would we then end up holding those new requests in the `Set` never to be cleared again because, I guess, `abortPendingRequests` won't be called again?

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

PR: https://git.openjdk.java.net/jdk/pull/7196

From dfuchs at openjdk.java.net  Wed Mar  9 12:35:02 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 9 Mar 2022 12:35:02 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task
In-Reply-To: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
Message-ID: <2Odd-nKihW9N0fDhsEhyjL-ND2tO8hzzERwCgqjHtF4=.a498ddad-e17d-40f3-99b2-06f4e2bfcd97@github.com>

On Mon, 24 Jan 2022 14:25:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> These changes make sure that pending requests are terminated if the selector manager thread exits due to exceptions.
> This includes:
>    1. completing CompletableFutures that were returned to the caller code
>    2. cancelling requests that are in flight
>    3. calling onError on BodySubscribers that may not have been completed
> Note that step 3 is necessary as certain CompletableFutures, such as those returned by `BodySubscribers.ofInputStream`, complete immediately, the operation being eventually completed when the last bite of the response is read. Completing a completable future that is already completed has no effect, this case is handled by completing the BodySubscriber too.

Thanks for your review Jaikiran!

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

PR: https://git.openjdk.java.net/jdk/pull/7196

From dfuchs at openjdk.java.net  Wed Mar  9 12:35:04 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 9 Mar 2022 12:35:04 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task
In-Reply-To: <vRO5bHf8ySbqvm_gVP4LkeurfRFkXipuYf2fos-eCvc=.7753acc6-62c2-45a7-89f9-fa91a30eafd7@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
 <vRO5bHf8ySbqvm_gVP4LkeurfRFkXipuYf2fos-eCvc=.7753acc6-62c2-45a7-89f9-fa91a30eafd7@github.com>
Message-ID: <HsbAwTuqj0H8taI8N9nR116ZOiM5dFezEY1VVHkFnmQ=.627609bb-4cd6-4ee7-ad25-2d81e062dfc9@github.com>

On Wed, 9 Mar 2022 10:04:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> These changes make sure that pending requests are terminated if the selector manager thread exits due to exceptions.
>> This includes:
>>    1. completing CompletableFutures that were returned to the caller code
>>    2. cancelling requests that are in flight
>>    3. calling onError on BodySubscribers that may not have been completed
>> Note that step 3 is necessary as certain CompletableFutures, such as those returned by `BodySubscribers.ofInputStream`, complete immediately, the operation being eventually completed when the last bite of the response is read. Completing a completable future that is already completed has no effect, this case is handled by completing the BodySubscriber too.
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1AsyncReceiver.java line 501:
> 
>> 499:             debug.log("recorded " + t + "\n\t delegate: " + delegate
>> 500:                       + "\n\t queue.isEmpty: " + queue.isEmpty()
>> 501:                       + " stopRequested: " + stopRequested, ex);
> 
> Should this also be preceded with a `\n\t ` to be consistent with the rest of this log message?

Good point - will do

> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 366:
> 
>> 364:                         refCountTracker.tryRelease();
>> 365:                     }
>> 366:                 });
> 
> I see that later in this code there's another `finally` block where we have now added a `tryRelease` call which first checks the `acquired` flag. A couple of questions:
> 1. Should this above line too first check the `acquire` flag?
> 2. Should we reset the `acquire` local variable once we `tryRelease` here so as to prevent another `tryRelease` in the other `finally`  block? A short glance at the implementation of `tryRelease` suggests that multiple `tryRelease()` with a single `acquire()` won't cause a problem in its state but it does end up logging some messages, which perhaps could be avoided.

tryRelease can be called multiple time - it will only decrement the ref counting once. It could happen when different threads notice that the operation is finished (usually due to some exceptions being propagated) and try concurrently to decrease the ref counter. It is very important to decrease the ref counter (otherwise the HttpClient may never shutdown when it's released) and equally very important not to decrease it twice for the same operation. Here we don't need to check whether it's been acquired because we know it's been acquired if we reach here. IIRC what we don't want to do is call tryRelease() if it's never been acquired.

> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 374:
> 
>> 372:                     cf.completeExceptionally(t);
>> 373:                 } finally {
>> 374:                     if (acquired) refCountTracker.tryRelease();
> 
> I see that before this change, we never did a `tryRelease` in this finally block. Was that a separate bug in itself and something that is being fixed as part of this PR?

I've been fighting with trying to get the ref counter back to 0 after Executor::shutdown has been called. 
Throwing TaskRejectedException (especially when `SequentialScheduler::runOrSchedule(Executor)` is called) is very disruptive to the logic.
In practice - it does not matter as much provided that all resources have been released and all body subscribers have been completed - and that's what this PR does.

> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 647:
> 
>> 645:             if (t instanceof EOFException && parser != null &&
>> 646:                     parser instanceof UnknownLengthBodyParser) {
>> 647:                 ((UnknownLengthBodyParser)parser).complete();
> 
> A minor note - while we are it, perhaps the new `instanceof` feature can be used here to avoid this cast?

Good point.

> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 728:
> 
>> 726:                 } else {
>> 727:                     if (debug.on()) {
>> 728:                         debug.log("no parser");
> 
> Should we perhaps log the error message (`Throwable::getMessage`) to provide some kind of hints in the logs when this message is logged? Perhaps `Ignoring error since no parser available: + error.getMessage()`?

Good idea

> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 179:
> 
>> 177:             } catch (Throwable t) {
>> 178:                 errorHandler.accept(command, t);
>> 179:                 ASYNC_POOL.execute(command);
> 
> Does this mean that we will now attempt to use an `ASYNC_POOL` even if a had supplied an `Executor`? The `CompletableFuture#defaultExecutor` which is what the `ASYNC_POOL` represents states:
> 
> Returns the default Executor used for async methods that do not specify an Executor.
> 
> which would now contradict with this code. With the error handler logic in place (one line above), do you think we should just give up on running the `command` instead of passing to the default executor?
> 
> Furthermore, if we do decide to use the default executor in cases like this, is that something that all implementations of the `HttpClient` are expected to do (i.e. would it be a specification) or is this more an implementation detail.

1. Dependent actions added by the caller to the CF returned by the HttpClient are executed in the FJP
2. This is an exceptional case - we're doing this only when we're shutting down the HttpClient. I don't think we should document it - this is an implementation detail. But we should probably document that shutting down the executor while operations are still in progress can lead to unpredictable/unspecified behavior.

Note: If we had VirtualThreads we would probably create a new VirtualThread here, rather than using the FJP.

> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 199:
> 
>> 197:     // the selector manager thread exists abnormally.
>> 198:     // The request, its id, and its completable future, are stored in a record-like
>> 199:     // PendingRequest object added to the pending requests set (pendingRequests).
> 
> I'm not too familiar with the HttpClient code yet. Before this change, was there ever a place where we would end up holding onto the request instances in memory and prevent them from being garbage collected? Would this change cause unintentional resource constraints in a regular/good scenario (where the `SelectorManager` thread hasn't exited abnormally and is still alive) or in cases where HTTP responses are slow to come back from servers?

In the normal course of action the HttpClient will not shutdown if any operation are still in progress. So holding onto the multiexchange here doesn't prevent the client from shutting down, since the multiexchange will be remove from this list when the operation completes.

> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 302:
> 
>> 300:             var msg = reason instanceof RejectedExecutionException
>> 301:                     ? reason.getClass() : reason;
>> 302:             client.debug.log("aborting pending requests due to: %s", msg);
> 
> Any reason why we are using a different log message for `RejectedExecutionException`? Would it instead be useful to let the underlying `message` from the `RejectedExecutionException` be logged too just like we are doing for other exception types here?

IIRC the message was too long and not very informative.

> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 308:
> 
>> 306:         while (!pendingRequests.isEmpty()) {
>> 307:             var pendings = pendingRequests.iterator();
>> 308:             while (pendings.hasNext()) {
> 
> Would there be a case where while we are aborting these current pending requests, some user code does a  `sendAsync` and we end up add a new pending request to the `Set`? Would we then end up holding those new requests in the `Set` never to be cleared again because, I guess, `abortPendingRequests` won't be called again?

I think that's been taken care of. The first thing we do is set up a flag that we're shutting down. I remember asking myself the same question and making sure it doesn't happen - that is - everything will be aborted.

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

PR: https://git.openjdk.java.net/jdk/pull/7196

From mullan at openjdk.java.net  Wed Mar  9 13:35:13 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 9 Mar 2022 13:35:13 GMT
Subject: RFR: 8280494: (D)TLS signature schemes [v20]
In-Reply-To: <EmTNtwmQwdJQud-Ot22G4Lo3NuAXmZMWxiRhyMYLyGg=.22aafb32-9c00-409f-98c5-3d22927a082d@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
 <EmTNtwmQwdJQud-Ot22G4Lo3NuAXmZMWxiRhyMYLyGg=.22aafb32-9c00-409f-98c5-3d22927a082d@github.com>
Message-ID: <RPG140Iug1moBCZYmmwY3VLibzVBF9EZ9rMQ2uMJQOU=.25d266b9-6852-463b-a0b2-2399cc0801d1@github.com>

On Wed, 9 Mar 2022 08:25:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494
>> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct test case issues and more

Marked as reviewed by mullan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7252

From michaelm at openjdk.java.net  Wed Mar  9 14:23:38 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 9 Mar 2022 14:23:38 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:

 - update
 - update after first review round

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7688/files
  - new: https://git.openjdk.java.net/jdk/pull/7688/files/f0fb72de..b765d412

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=00-01

  Stats: 168 lines in 12 files changed: 73 ins; 27 del; 68 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7688.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7688/head:pull/7688

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Wed Mar  9 14:31:04 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 9 Mar 2022 14:31:04 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <5mHz6hrcfrSlsZOjP7VFi0VhF3k29LBmX2xm8HpGiEI=.b7da60be-6b1e-492d-9100-1e4752d5a2b3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <5mHz6hrcfrSlsZOjP7VFi0VhF3k29LBmX2xm8HpGiEI=.b7da60be-6b1e-492d-9100-1e4752d5a2b3@github.com>
Message-ID: <E5O7U-cke-xmtUdLuvZ3ewOsqqEkPtqm3OdWQ-dqyb4=.dd228f70-946b-48db-8c9c-39a4f5c4bd28@github.com>

On Mon, 7 Mar 2022 20:35:13 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update
>>  - update after first review round
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 514:
> 
>> 512:         if (getAuthType() == AuthCacheValue.Type.Server &&
>> 513:                 getProtocolScheme().equals("https")) {
>> 514:             // HTTPS server authentication can use any algorithm
> 
> A more security conscious user may want to disable MD5 digest authentication, even when used over HTTPS, even though the risks are far less than when used over HTTP. Is there a way to do that?

There isn't a way to do that currently. I'd prefer not to further complicate the configuration to allow it. It would probably be a lot simpler to just disable MD5 across the board for proxy and server instead? We're including SHA-1 in that list now as well by the way.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From ssahoo at openjdk.java.net  Wed Mar  9 15:10:13 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Wed, 9 Mar 2022 15:10:13 GMT
Subject: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt
 should be case-insensitive
Message-ID: <SVBWH2-_dt8F-32pwoUSapzjkjK8tprOiBYC16NG-6A=.ca826485-c8f2-4328-aebb-e4be64bde5fa@github.com>

Domain value for system property jdk.https.negotiate.cbt  is case-insensitive now. Included Test has been updated to address the change.

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

Commit messages:
 - 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive

Changes: https://git.openjdk.java.net/jdk/pull/7759/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282293
  Stats: 10 lines in 2 files changed: 7 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7759.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7759/head:pull/7759

PR: https://git.openjdk.java.net/jdk/pull/7759

From dfuchs at openjdk.java.net  Wed Mar  9 15:48:10 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 9 Mar 2022 15:48:10 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
Message-ID: <3kRtdZOMt4k06pdbX4yxTHSyFR170ovb8_WqmDnXdiQ=.e5eace7f-8a52-4a54-8907-787619020ec6@github.com>

On Wed, 9 Mar 2022 14:23:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - update after first review round

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 82:

> 80:         @SuppressWarnings("removal")
> 81:         String secprops = AccessController.doPrivileged(
> 82:             new PrivilegedAction<>() {

could use a lambda instead of an anonymous class?

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 85:

> 83:                 public String run() {
> 84:                     return Security.getProperty(secPropName)
> 85:                                    .replaceAll("\\s", "")

`Security.getProperty` may return `null` so replacement should only be made after checking that it is non null.

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 94:

> 92:             disabledAlgs.add(algorithm);
> 93:         }
> 94:         return Collections.unmodifiableSet(disabledAlgs);

Could use `Set.copyOf()` ? Or is there anything that might call contains(null)? Also should strings be converted to upper case like below?

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 127:

> 125:                     String s = NetProperties.get(enabledAlgPropName);
> 126:                     return s == null
> 127:                         ? "" : s.replaceAll("\\s", "").toUpperCase();

Should probably use Local.ROOT to convert to upper case.
It seems to me that the code that takes a String as argument, check for null and returns an empty set, remove spaces, convert it to upper case, splits the string at commas, and create an immutable set from that, could be moved to an auxillary function and called for parsing both the Security property and the System property - since their syntax is identical.

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 397:

> 395:         params.setQop (p.findValue("qop"));
> 396:         params.setUserhash (Boolean.valueOf(p.findValue("userhash")));
> 397:         params.setCharset(p.findValue("charset", "ISO_8859_1").toUpperCase());

Should probably use Locale.ROOT when converting to upper case

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 426:

> 424:             algorithm = "MD5";  // The default, accoriding to rfc2069
> 425:         }
> 426:         algorithm = algorithm.toUpperCase();

same here

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From weijun at openjdk.java.net  Wed Mar  9 15:48:11 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 9 Mar 2022 15:48:11 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
Message-ID: <IIqvZzHFRm9LdEpoPovQ4raPo31bt6EUvAkloXIzLB8=.e98dd4b0-b32a-4bf9-8bcf-519905ccfd10@github.com>

On Wed, 9 Mar 2022 14:23:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - update after first review round

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 99:

> 97:     // A net property which overrides the disabled set above.
> 98:     private static final String enabledAlgPropName =
> 99:         "http.auth.digest.enabledAlgorithms";

I'm not familiar with the practice of overriding a security property with a net property. Just FYI, in security libs, we often override a security property with a system property and we have a dedicated method for this at https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/security/util/SecurityProperties.java#L46.

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 232:

> 230:                 ? StandardCharsets.UTF_8
> 231:                 : StandardCharsets.ISO_8859_1;
> 232:         }

Do you want to reject other values? According to the RFC, `utf-8` is the only valid one.

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 426:

> 424:             algorithm = "MD5";  // The default, accoriding to rfc2069
> 425:         }
> 426:         algorithm = algorithm.toUpperCase();

Please use `toUpperCase(Locale.ROOT)` or `toUpperCase(Locale.ENGLISH)`.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Wed Mar  9 15:53:02 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 9 Mar 2022 15:53:02 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
Message-ID: <yVGWJxRIEL1pTSkhrNxyxYg3krcbXauuKqx9Y4R3vxQ=.c4db9e2d-fc45-4a46-b040-38ad224787d6@github.com>

On Wed, 9 Mar 2022 14:23:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - update after first review round

Should we have a test case for "SHA-512-256" too?

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Wed Mar  9 15:56:03 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 9 Mar 2022 15:56:03 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <3kRtdZOMt4k06pdbX4yxTHSyFR170ovb8_WqmDnXdiQ=.e5eace7f-8a52-4a54-8907-787619020ec6@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <3kRtdZOMt4k06pdbX4yxTHSyFR170ovb8_WqmDnXdiQ=.e5eace7f-8a52-4a54-8907-787619020ec6@github.com>
Message-ID: <Xt2qm_YPByS8MpBj7hHN2c-nwh9j5bS6LEQOJWoyg8g=.2cd5a0c0-1e6c-46b4-8aa7-37bbfab239f7@github.com>

On Wed, 9 Mar 2022 15:18:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update
>>  - update after first review round
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 85:
> 
>> 83:                 public String run() {
>> 84:                     return Security.getProperty(secPropName)
>> 85:                                    .replaceAll("\\s", "")
> 
> `Security.getProperty` may return `null` so replacement should only be made after checking that it is non null.

Maybe `String.trim()` should be called on each element after splitting instead: you want to remove spaces before and after commas, not necessarily spaces within a name. "MD 5, SHA-256" probably shouldn't be parsed as "MD5,SHA-256".

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From xuelei at openjdk.java.net  Wed Mar  9 16:15:14 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 9 Mar 2022 16:15:14 GMT
Subject: Integrated: 8280494: (D)TLS signature schemes
In-Reply-To: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
References: <qtDbG-9bkTPSWR-zMcKQBNfz7FMmH2FI6mf7Ef_42-Y=.1aeb8e27-dafb-4c73-9a36-d710ba280524@github.com>
Message-ID: <7yb7x6f1PGi17KAySfeI2YY24rTy2DWKmaJbyTzQI6I=.cbfc191a-e6b3-4b67-bb14-81ae60cc5636@github.com>

On Thu, 27 Jan 2022 22:06:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494
> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290

This pull request has now been integrated.

Changeset: 6d8d156c
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6d8d156c97b90a9ab4776c6b42563a962d959741
Stats:     521 lines in 6 files changed: 462 ins; 12 del; 47 mod

8280494: (D)TLS signature schemes

Reviewed-by: mullan

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

PR: https://git.openjdk.java.net/jdk/pull/7252

From xuelei at openjdk.java.net  Wed Mar  9 16:47:00 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 9 Mar 2022 16:47:00 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v4]
In-Reply-To: <scn9daKYtSwX95QlW1vDh7c1e3bJZAimgsaN6w80l0w=.e3934b85-32a7-4884-8f19-27e8b6b2b416@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <scn9daKYtSwX95QlW1vDh7c1e3bJZAimgsaN6w80l0w=.e3934b85-32a7-4884-8f19-27e8b6b2b416@github.com>
Message-ID: <pWACeOhadcoEZ4SKB0ijpdZeE6Drr2uaWTvlK641GwE=.013821a9-043a-4ceb-aad7-a5624a84c2b2@github.com>

On Tue, 8 Mar 2022 15:03:57 GMT, zzambers <duke at openjdk.java.net> wrote:

>> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
>> [2] https://bugs.openjdk.java.net/browse/JDK-8216326
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small fixes

Marked as reviewed by xuelei (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From dfuchs at openjdk.java.net  Wed Mar  9 16:54:58 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 9 Mar 2022 16:54:58 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task [v2]
In-Reply-To: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
Message-ID: <df4OhRVObdQATO3jr7TmBQlHnebZ5j9rDL7_70isKK4=.b52f13fc-05e4-4f33-8900-1758dca6f30c@github.com>

> These changes make sure that pending requests are terminated if the selector manager thread exits due to exceptions.
> This includes:
>    1. completing CompletableFutures that were returned to the caller code
>    2. cancelling requests that are in flight
>    3. calling onError on BodySubscribers that may not have been completed
> Note that step 3 is necessary as certain CompletableFutures, such as those returned by `BodySubscribers.ofInputStream`, complete immediately, the operation being eventually completed when the last bite of the response is read. Completing a completable future that is already completed has no effect, this case is handled by completing the BodySubscriber too.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Incorporated review comments
 - Merge branch 'master' into executor-shutdown-8277969
 - 8277969: HttpClient SelectorManager shuts down when custom Executor rejects a task

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7196/files
  - new: https://git.openjdk.java.net/jdk/pull/7196/files/9ad98bdf..6c6f3f1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7196&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7196&range=00-01

  Stats: 66043 lines in 1879 files changed: 45834 ins; 10687 del; 9522 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7196.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7196/head:pull/7196

PR: https://git.openjdk.java.net/jdk/pull/7196

From achung at openjdk.java.net  Wed Mar  9 21:16:48 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 9 Mar 2022 21:16:48 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
Message-ID: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>

msg drop for jdk19, Mar 9, 2022

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

Commit messages:
 - open jdk19 l10n msg drop

Changes: https://git.openjdk.java.net/jdk/pull/7765/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280400
  Stats: 13775 lines in 142 files changed: 12170 ins; 1249 del; 356 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765

From naoto at openjdk.java.net  Wed Mar  9 22:29:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 9 Mar 2022 22:29:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <PBk3nk8e8eclzDy8yKIrJOgKLqveAK3NoSqrAzra6fg=.3dbfe55e-2394-4ee6-bd3b-43b558c02ef7@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

`src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties`
`src/java.base/share/classes/sun/util/resources/CurrencyNames_ja.properties`
`src/java.base/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties`

These are part of `jdk.localedata` module. Should be excluded from `java.base` module and apply the diffs to `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_xx.properties` manually. (Note that the first half of it is not necessary when merging).

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From joehw at openjdk.java.net  Thu Mar 10 00:46:44 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 10 Mar 2022 00:46:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <8oYKi_L4IgNDFUfJ9uXlSl47KULO4j1HudfJg3kVeCU=.90fa019e-8b6f-4a69-870b-cd53c8802490@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

For the bundles in java.xml:

For files with Oracle copyright, update the year to 2022 and @LastModified Mar 2022. Take XPATHErrorResources_ja.java as an example, the copyright year was updated to 2021 and @LastModified: Nov 2021. That's probably the date it was last modified, but as we updating them now along with a number of other files, it would be good to be consistent and change all of them to the current date.

For files with the reserved comment block such as SerializerMessages_de.java, do the same as did in XPATHErrorResources_de.java, add the copyright header and LastModified tag with the current date. 

For files with the Oracle GPL license such as message_zh_CN.properties, do not delete the license header. Instead, update the copyright year to 2022 if there are changes. I don't see any changes were made for many of these files, for example from msg/XMLSchemaMessages_ja.properties to regex/message_zh_CN.properties, the only change was the removal of the header.

In the webrev view, some files have the word "undefined" right under the license header, hopefully once the license header is fixed, that would go away as well.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From ssahoo at openjdk.java.net  Thu Mar 10 05:59:14 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Thu, 10 Mar 2022 05:59:14 GMT
Subject: RFR: 8282293: Domain value for system property
 jdk.https.negotiate.cbt should be case-insensitive [v2]
In-Reply-To: <SVBWH2-_dt8F-32pwoUSapzjkjK8tprOiBYC16NG-6A=.ca826485-c8f2-4328-aebb-e4be64bde5fa@github.com>
References: <SVBWH2-_dt8F-32pwoUSapzjkjK8tprOiBYC16NG-6A=.ca826485-c8f2-4328-aebb-e4be64bde5fa@github.com>
Message-ID: <c0YBds7s64SxmD1IlEcR--WgO7TVcm6aY59D1w_iA28=.7d83b765-0f9e-4aa5-b2fb-f211f7a1413f@github.com>

> Domain value for system property jdk.https.negotiate.cbt  is case-insensitive now. Included Test has been updated to address the change.

Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:

  Update HttpsCB.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7759/files
  - new: https://git.openjdk.java.net/jdk/pull/7759/files/6899fe36..6d276479

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7759

From jpai at openjdk.java.net  Thu Mar 10 10:11:45 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 10 Mar 2022 10:11:45 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task [v2]
In-Reply-To: <HsbAwTuqj0H8taI8N9nR116ZOiM5dFezEY1VVHkFnmQ=.627609bb-4cd6-4ee7-ad25-2d81e062dfc9@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
 <vRO5bHf8ySbqvm_gVP4LkeurfRFkXipuYf2fos-eCvc=.7753acc6-62c2-45a7-89f9-fa91a30eafd7@github.com>
 <HsbAwTuqj0H8taI8N9nR116ZOiM5dFezEY1VVHkFnmQ=.627609bb-4cd6-4ee7-ad25-2d81e062dfc9@github.com>
Message-ID: <C55iCVTUdv14NwGP8K4vYL2V36X3SQz9xunjvUtaeJs=.22c55625-b87b-47a6-8e2f-24c69b26d679@github.com>

On Wed, 9 Mar 2022 11:55:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Here we don't need to check whether it's been acquired because we know it's been acquired if we reach here.

Hello Daniel, may be I am misreading the diff but from what I can see, the `acquire()` method now returns a `boolean` which we are assigning to the local `acquire`. But we aren't checking it for `true` for doing the subsequent operation. So when it reaches the finally block here, as far as I can see, it's not guaranteed that we did indeed `acquire` it.

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

PR: https://git.openjdk.java.net/jdk/pull/7196

From jpai at openjdk.java.net  Thu Mar 10 10:16:46 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 10 Mar 2022 10:16:46 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task [v2]
In-Reply-To: <HsbAwTuqj0H8taI8N9nR116ZOiM5dFezEY1VVHkFnmQ=.627609bb-4cd6-4ee7-ad25-2d81e062dfc9@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
 <vRO5bHf8ySbqvm_gVP4LkeurfRFkXipuYf2fos-eCvc=.7753acc6-62c2-45a7-89f9-fa91a30eafd7@github.com>
 <HsbAwTuqj0H8taI8N9nR116ZOiM5dFezEY1VVHkFnmQ=.627609bb-4cd6-4ee7-ad25-2d81e062dfc9@github.com>
Message-ID: <F2IO72MZHcAFnRI8QzkP8Sbx99-Dzi_ea2WR3zGN6vw=.4162bde0-d4ce-402c-b565-24bda4e877ff@github.com>

On Wed, 9 Mar 2022 12:09:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 179:
>> 
>>> 177:             } catch (Throwable t) {
>>> 178:                 errorHandler.accept(command, t);
>>> 179:                 ASYNC_POOL.execute(command);
>> 
>> Does this mean that we will now attempt to use an `ASYNC_POOL` even if a had supplied an `Executor`? The `CompletableFuture#defaultExecutor` which is what the `ASYNC_POOL` represents states:
>> 
>> Returns the default Executor used for async methods that do not specify an Executor.
>> 
>> which would now contradict with this code. With the error handler logic in place (one line above), do you think we should just give up on running the `command` instead of passing to the default executor?
>> 
>> Furthermore, if we do decide to use the default executor in cases like this, is that something that all implementations of the `HttpClient` are expected to do (i.e. would it be a specification) or is this more an implementation detail.
>
> 1. Dependent actions added by the caller to the CF returned by the HttpClient are executed in the FJP
> 2. This is an exceptional case - we're doing this only when we're shutting down the HttpClient. I don't think we should document it - this is an implementation detail. But we should probably document that shutting down the executor while operations are still in progress can lead to unpredictable/unspecified behavior.
> 
> Note: If we had VirtualThreads we would probably create a new VirtualThread here, rather than using the FJP.

Thank you for that clarification, especially this part which I wasn't aware of:

> 1. Dependent actions added by the caller to the CF returned by the HttpClient are executed in the FJP

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

PR: https://git.openjdk.java.net/jdk/pull/7196

From dfuchs at openjdk.java.net  Thu Mar 10 10:34:43 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 10:34:43 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <p1RcBIafcDBf0k6FeY60oiHc94CG5wc5mJMDaNAO7js=.1bce7a1c-81cd-475d-bcbb-4423a5040b6b@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

For simple webserver resource files - should the copyright year be 2022?

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From dfuchs at openjdk.java.net  Thu Mar 10 10:44:38 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 10:44:38 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task [v2]
In-Reply-To: <C55iCVTUdv14NwGP8K4vYL2V36X3SQz9xunjvUtaeJs=.22c55625-b87b-47a6-8e2f-24c69b26d679@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
 <vRO5bHf8ySbqvm_gVP4LkeurfRFkXipuYf2fos-eCvc=.7753acc6-62c2-45a7-89f9-fa91a30eafd7@github.com>
 <HsbAwTuqj0H8taI8N9nR116ZOiM5dFezEY1VVHkFnmQ=.627609bb-4cd6-4ee7-ad25-2d81e062dfc9@github.com>
 <C55iCVTUdv14NwGP8K4vYL2V36X3SQz9xunjvUtaeJs=.22c55625-b87b-47a6-8e2f-24c69b26d679@github.com>
Message-ID: <vMO5UIIga7WVmB2F-p3pkcVFb9VXdBkqXq00TJLOqYI=.97da71f0-97d7-4e7b-91a8-39b029e6bb87@github.com>

On Thu, 10 Mar 2022 10:08:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> tryRelease can be called multiple time - it will only decrement the ref counting once. It could happen when different threads notice that the operation is finished (usually due to some exceptions being propagated) and try concurrently to decrease the ref counter. It is very important to decrease the ref counter (otherwise the HttpClient may never shutdown when it's released) and equally very important not to decrease it twice for the same operation. Here we don't need to check whether it's been acquired because we know it's been acquired if we reach here. IIRC what we don't want to do is call tryRelease() if it's never been acquired.
>
>> Here we don't need to check whether it's been acquired because we know it's been acquired if we reach here.
> 
> Hello Daniel, may be I am misreading the diff but from what I can see, the `acquire()` method now returns a `boolean` which we are assigning to the local `acquire`. But we aren't checking it for `true` for doing the subsequent operation. So when it reaches the finally block here, as far as I can see, it's not guaranteed that we did indeed `acquire` it.

The acquire() method will return true the first time it's been called. And it is called only once. So we only need to check whether `acquired` is true at places where we are in doubt about whether the method has been called.
The code that calls acquire() above could simply have ignored the result of `acquire()` and set the boolean to `true`. That said, it would not be wrong to check whether `acquired==true` here too - maybe I should do it for consistency...

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

PR: https://git.openjdk.java.net/jdk/pull/7196

From michaelm at openjdk.java.net  Thu Mar 10 10:51:40 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Mar 2022 10:51:40 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <Xt2qm_YPByS8MpBj7hHN2c-nwh9j5bS6LEQOJWoyg8g=.2cd5a0c0-1e6c-46b4-8aa7-37bbfab239f7@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <3kRtdZOMt4k06pdbX4yxTHSyFR170ovb8_WqmDnXdiQ=.e5eace7f-8a52-4a54-8907-787619020ec6@github.com>
 <Xt2qm_YPByS8MpBj7hHN2c-nwh9j5bS6LEQOJWoyg8g=.2cd5a0c0-1e6c-46b4-8aa7-37bbfab239f7@github.com>
Message-ID: <UQuWmLCM5iFBSbCSRmL-nup6i7ZsxD8P9h-QxsgVvTM=.0a72b78d-dd3b-43d4-93ba-974ba53470be@github.com>

On Wed, 9 Mar 2022 15:53:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 85:
>> 
>>> 83:                 public String run() {
>>> 84:                     return Security.getProperty(secPropName)
>>> 85:                                    .replaceAll("\\s", "")
>> 
>> `Security.getProperty` may return `null` so replacement should only be made after checking that it is non null.
>
> Maybe `String.trim()` should be called on each element after splitting instead: you want to remove spaces before and after commas, not necessarily spaces within a name. "MD 5, SHA-256" probably shouldn't be parsed as "MD5,SHA-256".

Okay.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Thu Mar 10 10:51:41 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Mar 2022 10:51:41 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <IIqvZzHFRm9LdEpoPovQ4raPo31bt6EUvAkloXIzLB8=.e98dd4b0-b32a-4bf9-8bcf-519905ccfd10@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <IIqvZzHFRm9LdEpoPovQ4raPo31bt6EUvAkloXIzLB8=.e98dd4b0-b32a-4bf9-8bcf-519905ccfd10@github.com>
Message-ID: <rfc3PbzgFsMjcR7sXhw1z8waEG7OU29sKX5zFhtPkuc=.82cedbc8-0697-4b75-85fe-47e0aff78687@github.com>

On Wed, 9 Mar 2022 14:23:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update
>>  - update after first review round
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 99:
> 
>> 97:     // A net property which overrides the disabled set above.
>> 98:     private static final String enabledAlgPropName =
>> 99:         "http.auth.digest.enabledAlgorithms";
> 
> I'm not familiar with the practice of overriding a security property with a net property. Just FYI, in security libs, we often override a security property with a system property and we have a dedicated method for this at https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/security/util/SecurityProperties.java#L46.

A net property can be a system property. But, it can also be specified in the net.properties file. We're using different names for the security and net property as the security property specifies algortithms to be disabled and the net property ones to be (re)enabled.

> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 232:
> 
>> 230:                 ? StandardCharsets.UTF_8
>> 231:                 : StandardCharsets.ISO_8859_1;
>> 232:         }
> 
> Do you want to reject other values? According to the RFC, `utf-8` is the only valid one.

You mean reject the whole response as a protocol error? I guess we probably should do that.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Thu Mar 10 11:00:49 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Mar 2022 11:00:49 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <3kRtdZOMt4k06pdbX4yxTHSyFR170ovb8_WqmDnXdiQ=.e5eace7f-8a52-4a54-8907-787619020ec6@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <3kRtdZOMt4k06pdbX4yxTHSyFR170ovb8_WqmDnXdiQ=.e5eace7f-8a52-4a54-8907-787619020ec6@github.com>
Message-ID: <FrJRDYlB6GxPABseY-Z7kWuPK-IlYna1buJL_IlQopE=.8af6815d-4283-4687-af89-8645376af986@github.com>

On Wed, 9 Mar 2022 15:18:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update
>>  - update after first review round
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 82:
> 
>> 80:         @SuppressWarnings("removal")
>> 81:         String secprops = AccessController.doPrivileged(
>> 82:             new PrivilegedAction<>() {
> 
> could use a lambda instead of an anonymous class?

Had tried it first and compiler didn't know whether lambda is a PrivilegedAction or a PrivilegedExceptionAction, but it seems a cast works. Will change it.

> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 127:
> 
>> 125:                     String s = NetProperties.get(enabledAlgPropName);
>> 126:                     return s == null
>> 127:                         ? "" : s.replaceAll("\\s", "").toUpperCase();
> 
> Should probably use Local.ROOT to convert to upper case.
> It seems to me that the code that takes a String as argument, check for null and returns an empty set, remove spaces, convert it to upper case, splits the string at commas, and create an immutable set from that, could be moved to an auxillary function and called for parsing both the Security property and the System property - since their syntax is identical.

good idea

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From jpai at openjdk.java.net  Thu Mar 10 11:00:51 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 10 Mar 2022 11:00:51 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task [v2]
In-Reply-To: <df4OhRVObdQATO3jr7TmBQlHnebZ5j9rDL7_70isKK4=.b52f13fc-05e4-4f33-8900-1758dca6f30c@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
 <df4OhRVObdQATO3jr7TmBQlHnebZ5j9rDL7_70isKK4=.b52f13fc-05e4-4f33-8900-1758dca6f30c@github.com>
Message-ID: <DHs1dlq1Bn8B6wHvWp_teZRZPobKcnkdKT20NLi179E=.c6048440-5996-402c-9c3a-df2339706a38@github.com>

On Wed, 9 Mar 2022 16:54:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> These changes make sure that pending requests are terminated if the selector manager thread exits due to exceptions.
>> This includes:
>>    1. completing CompletableFutures that were returned to the caller code
>>    2. cancelling requests that are in flight
>>    3. calling onError on BodySubscribers that may not have been completed
>> Note that step 3 is necessary as certain CompletableFutures, such as those returned by `BodySubscribers.ofInputStream`, complete immediately, the operation being eventually completed when the last bite of the response is read. Completing a completable future that is already completed has no effect, this case is handled by completing the BodySubscriber too.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Incorporated review comments
>  - Merge branch 'master' into executor-shutdown-8277969
>  - 8277969: HttpClient SelectorManager shuts down when custom Executor rejects a task

I went over the remaining changes in this PR and to me these changes look fine.

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

PR: https://git.openjdk.java.net/jdk/pull/7196

From michaelm at openjdk.java.net  Thu Mar 10 11:00:50 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Mar 2022 11:00:50 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <IIqvZzHFRm9LdEpoPovQ4raPo31bt6EUvAkloXIzLB8=.e98dd4b0-b32a-4bf9-8bcf-519905ccfd10@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <IIqvZzHFRm9LdEpoPovQ4raPo31bt6EUvAkloXIzLB8=.e98dd4b0-b32a-4bf9-8bcf-519905ccfd10@github.com>
Message-ID: <7jF5uQ38UGQq85LOcb-dqArfZ0tqsyEk8OQ6yDqoeBE=.9d0993d2-7a2f-4fe0-aaed-a83fcf92dd21@github.com>

On Wed, 9 Mar 2022 15:41:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update
>>  - update after first review round
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 426:
> 
>> 424:             algorithm = "MD5";  // The default, accoriding to rfc2069
>> 425:         }
>> 426:         algorithm = algorithm.toUpperCase();
> 
> Please use `toUpperCase(Locale.ROOT)` or `toUpperCase(Locale.ENGLISH)`.

> Should we have a test case for "SHA-512-256" too?

If there's hardcoded example in the RFC, I will include it

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Thu Mar 10 11:17:26 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 11:17:26 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task [v3]
In-Reply-To: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
Message-ID: <cQASI85evCubOTVuUDuEG5UlMPSsp9svsC5XLQH_FHQ=.3a336795-cd96-4acf-8f19-e2e04d3da4ae@github.com>

> These changes make sure that pending requests are terminated if the selector manager thread exits due to exceptions.
> This includes:
>    1. completing CompletableFutures that were returned to the caller code
>    2. cancelling requests that are in flight
>    3. calling onError on BodySubscribers that may not have been completed
> Note that step 3 is necessary as certain CompletableFutures, such as those returned by `BodySubscribers.ofInputStream`, complete immediately, the operation being eventually completed when the last bite of the response is read. Completing a completable future that is already completed has no effect, this case is handled by completing the BodySubscriber too.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  asserts that acquired == true

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7196/files
  - new: https://git.openjdk.java.net/jdk/pull/7196/files/6c6f3f1a..90ab52de

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7196&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7196&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/7196

From jpai at openjdk.java.net  Thu Mar 10 11:17:27 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 10 Mar 2022 11:17:27 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task [v3]
In-Reply-To: <vMO5UIIga7WVmB2F-p3pkcVFb9VXdBkqXq00TJLOqYI=.97da71f0-97d7-4e7b-91a8-39b029e6bb87@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
 <vRO5bHf8ySbqvm_gVP4LkeurfRFkXipuYf2fos-eCvc=.7753acc6-62c2-45a7-89f9-fa91a30eafd7@github.com>
 <HsbAwTuqj0H8taI8N9nR116ZOiM5dFezEY1VVHkFnmQ=.627609bb-4cd6-4ee7-ad25-2d81e062dfc9@github.com>
 <C55iCVTUdv14NwGP8K4vYL2V36X3SQz9xunjvUtaeJs=.22c55625-b87b-47a6-8e2f-24c69b26d679@github.com>
 <vMO5UIIga7WVmB2F-p3pkcVFb9VXdBkqXq00TJLOqYI=.97da71f0-97d7-4e7b-91a8-39b029e6bb87@github.com>
Message-ID: <mA6W-e5yhWP6ylvsPRasCElP_lEw8emZ2DLxjyKB_nI=.ed79ecd0-c5fc-49e1-a7bb-01e5b62931b7@github.com>

On Thu, 10 Mar 2022 10:41:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The acquire() method will return true the first time it's been called. And it is called only once. So we only need to check whether acquired is true at places where we are in doubt about whether the method has been called.

I see what you mean.

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

PR: https://git.openjdk.java.net/jdk/pull/7196

From dfuchs at openjdk.java.net  Thu Mar 10 11:17:28 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 11:17:28 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task [v3]
In-Reply-To: <mA6W-e5yhWP6ylvsPRasCElP_lEw8emZ2DLxjyKB_nI=.ed79ecd0-c5fc-49e1-a7bb-01e5b62931b7@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
 <vRO5bHf8ySbqvm_gVP4LkeurfRFkXipuYf2fos-eCvc=.7753acc6-62c2-45a7-89f9-fa91a30eafd7@github.com>
 <HsbAwTuqj0H8taI8N9nR116ZOiM5dFezEY1VVHkFnmQ=.627609bb-4cd6-4ee7-ad25-2d81e062dfc9@github.com>
 <C55iCVTUdv14NwGP8K4vYL2V36X3SQz9xunjvUtaeJs=.22c55625-b87b-47a6-8e2f-24c69b26d679@github.com>
 <vMO5UIIga7WVmB2F-p3pkcVFb9VXdBkqXq00TJLOqYI=.97da71f0-97d7-4e7b-91a8-39b029e6bb87@github.com>
 <mA6W-e5yhWP6ylvsPRasCElP_lEw8emZ2DLxjyKB_nI=.ed79ecd0-c5fc-49e1-a7bb-01e5b62931b7@github.com>
Message-ID: <M4Vaeb69gbI8qRfMFjx7VHwMPSdXZMlLOEFU7ijcEE4=.5df8347d-22af-406a-8773-99e6af1065fc@github.com>

On Thu, 10 Mar 2022 10:44:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The acquire() method will return true the first time it's been called. And it is called only once. So we only need to check whether `acquired` is true at places where we are in doubt about whether the method has been called.
>> The code that calls acquire() above could simply have ignored the result of `acquire()` and set the boolean to `true`. That said, it would not be wrong to check whether `acquired==true` here too - maybe I should do it for consistency...
>
>> The acquire() method will return true the first time it's been called. And it is called only once. So we only need to check whether acquired is true at places where we are in doubt about whether the method has been called.
> 
> I see what you mean.

Instead of checking `acquired`  in the lambda - which requires `acquired` being final, I will add a line to assert that `assert acquired == true` after calling `acquire()`.

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

PR: https://git.openjdk.java.net/jdk/pull/7196

From dfuchs at openjdk.java.net  Thu Mar 10 11:24:41 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 11:24:41 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <FrJRDYlB6GxPABseY-Z7kWuPK-IlYna1buJL_IlQopE=.8af6815d-4283-4687-af89-8645376af986@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <3kRtdZOMt4k06pdbX4yxTHSyFR170ovb8_WqmDnXdiQ=.e5eace7f-8a52-4a54-8907-787619020ec6@github.com>
 <FrJRDYlB6GxPABseY-Z7kWuPK-IlYna1buJL_IlQopE=.8af6815d-4283-4687-af89-8645376af986@github.com>
Message-ID: <Rpx3rOttLDqow6uMYrK0sd2Dy3QcJBkXiQuYOgI0V9k=.9746dbdb-355f-428e-8cae-7660c115285f@github.com>

On Thu, 10 Mar 2022 10:54:52 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 82:
>> 
>>> 80:         @SuppressWarnings("removal")
>>> 81:         String secprops = AccessController.doPrivileged(
>>> 82:             new PrivilegedAction<>() {
>> 
>> could use a lambda instead of an anonymous class?
>
> Had tried it first and compiler didn't know whether lambda is a PrivilegedAction or a PrivilegedExceptionAction, but it seems a cast works. Will change it.

or declare a local variable that holds the lambda - that would avoid the cast.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Thu Mar 10 15:29:46 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 15:29:46 GMT
Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer,
 HttpTransaction, HttpCallback from open/test/jdk/ tests [v5]
In-Reply-To: <XgeD9yoyADCts8svvhT6tr6k3vBEVCTejnE15ypw8qg=.45e3eff7-5cf2-4f4d-923a-112e5d7c4357@github.com>
References: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
 <XgeD9yoyADCts8svvhT6tr6k3vBEVCTejnE15ypw8qg=.45e3eff7-5cf2-4f4d-923a-112e5d7c4357@github.com>
Message-ID: <Jk2u9wI2HvSETNSA2gt1hF6xF1ScfBEXdQvgP9RCIak=.40edacec-5676-4d94-a70a-18817df54931@github.com>

On Fri, 4 Mar 2022 12:28:41 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

>> Updated following remaining tests to remove depenedies of TestHttpServer, HttpTransaction, HttpCallback
>> open/test/jdk/java/net/ProxySelector/LoopbackAddresses.java
>> open/test/jdk/java/net/ProxySelector/ProxyTest.java
>> open/test/jdk/java/net/URL/PerConnectionProxy.java
>> open/test/jdk/java/net/URLConnection/B5052093.java
>> open/test/jdk/sun/net/www/AuthHeaderTest.java
>> open/test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
>
> Mahendra Chhipa 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 11 additional commits since the last revision:
> 
>  - Removed extra space.
>  - Removed Transfer encoding chunked from B5045306
>  - Merge branch 'master' into JDK-8282354
>  - Implemented the review comments.
>  - Removed extra whitespace
>  - Implemented the review comments.
>  - JDK-8282354 : Remove dependancy of TestHttpServer, HttpTransaction, HttpCallback from open/test/jdk/ tests
>  - Merge branch 'master' into JDK-8282354
>  - WIP
>  - Merge branch 'master' into httptrans
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/f6e7b6e0...7f947718

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7616

From weijun at openjdk.java.net  Thu Mar 10 15:35:52 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 10 Mar 2022 15:35:52 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
Message-ID: <H5SBSVBHiBh7OxKyep6sgBRZrz7ak3R0EDIDUAxaUE8=.0b287e26-08a3-4203-bf29-f63d8fa5fc7f@github.com>

On Wed, 9 Mar 2022 14:23:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - update after first review round

src/java.base/share/classes/java/net/doc-files/net-properties.html line 234:

> 232:         in the {@code java.security} properties file and currently comprises {@code MD5} and
> 233:         {@code SHA-1}. If it is still required to use one of these algorithms, then they can be
> 234:         re-enabled by setting this property to a comma separated list of the algorithm names.</P>

Can we use "re-enabled" in the property name? To me, the name "enabled" sounds like all enabled algorithms are listed here.

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 68:

> 66: 
> 67:     private static final String secPropName =
> 68:         "jdk.httpdigest.defaultDisabledAlgorithms";

How about a dot between "http" and "digest"?

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 76:

> 74:     // used for proxy connections, or plain text http server connections
> 75: 
> 76:     private static final Set<String> defDisabledAlgs = getDefaultAlgs();

Can we move this field into a local variable in the static block near line 120? After all it's the `disabledAlgs` field finally gets used and the `defDisabledAlgs` is only used to calculate it?

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 78:

> 76:     private static final Set<String> defDisabledAlgs = getDefaultAlgs();
> 77: 
> 78:     private static Set<String> getDefaultAlgs() {

How about rename the method to include "disabled"?

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 693:

> 691:         }
> 692:         md.update(src.getBytes(charset));
> 693:         if (passwd != null) {

[RFC7616 ](https://datatracker.ietf.org/doc/html/rfc7616#section-4) says the password should also support unicode. It's OK we use the old code for compatibility reason.

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 701:

> 699:         }
> 700:         byte[] digest = md.digest();
> 701:         StringBuilder res = new StringBuilder(digest.length * 2);

Can we use `HexFormat` to encode the bytes?

src/java.base/share/conf/security/java.security line 711:

> 709: # separated list of algorithms to be allowed.
> 710: #
> 711: jdk.httpdigest.defaultDisabledAlgorithms = MD5, MD-5, SHA1, SHA-1

I haven't seen people using "MD-5". It's also not an alias of "MD5" in our own security providers. On the other hand, we support both "SHA1" and "SHA" (and its OID) as aliases of "SHA-1". So, either we list all these aliases here, or we only put the standard names here and "canonicalize" the name when we see one. `sun.security.util.KnownOIDs.findMatch("SHA-1").stdName()` can be used.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From weijun at openjdk.java.net  Thu Mar 10 15:35:52 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 10 Mar 2022 15:35:52 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <UQuWmLCM5iFBSbCSRmL-nup6i7ZsxD8P9h-QxsgVvTM=.0a72b78d-dd3b-43d4-93ba-974ba53470be@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <3kRtdZOMt4k06pdbX4yxTHSyFR170ovb8_WqmDnXdiQ=.e5eace7f-8a52-4a54-8907-787619020ec6@github.com>
 <Xt2qm_YPByS8MpBj7hHN2c-nwh9j5bS6LEQOJWoyg8g=.2cd5a0c0-1e6c-46b4-8aa7-37bbfab239f7@github.com>
 <UQuWmLCM5iFBSbCSRmL-nup6i7ZsxD8P9h-QxsgVvTM=.0a72b78d-dd3b-43d4-93ba-974ba53470be@github.com>
Message-ID: <U2e92Y4WuTAnv3IQt8sSCZCgFR8wpbJh0CZUAK6vwYY=.c235e9cf-4f54-4a79-8bf0-003c4c19dfcc@github.com>

On Thu, 10 Mar 2022 10:48:09 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Maybe `String.trim()` should be called on each element after splitting instead: you want to remove spaces before and after commas, not necessarily spaces within a name. "MD 5, SHA-256" probably shouldn't be parsed as "MD5,SHA-256".
>
> Okay.

`s.n.w.p.h.HttpURLConnection::schemesListToSet` uses `list.split("\\s*,\\s*")` which ignores multiple consecutive spaces as well. Can we make it a helper method somewhere?

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Thu Mar 10 16:46:50 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Mar 2022 16:46:50 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <H5SBSVBHiBh7OxKyep6sgBRZrz7ak3R0EDIDUAxaUE8=.0b287e26-08a3-4203-bf29-f63d8fa5fc7f@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <H5SBSVBHiBh7OxKyep6sgBRZrz7ak3R0EDIDUAxaUE8=.0b287e26-08a3-4203-bf29-f63d8fa5fc7f@github.com>
Message-ID: <q6SGsvdwndS2tvOX1auIz-FxGrGFsXwP08S2w-cAnFQ=.45c130e0-feba-47c9-8797-806527a6f214@github.com>

On Thu, 10 Mar 2022 14:21:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update
>>  - update after first review round
>
> src/java.base/share/conf/security/java.security line 711:
> 
>> 709: # separated list of algorithms to be allowed.
>> 710: #
>> 711: jdk.httpdigest.defaultDisabledAlgorithms = MD5, MD-5, SHA1, SHA-1
> 
> I haven't seen people using "MD-5". It's also not an alias of "MD5" in our own security providers. On the other hand, we support both "SHA1" and "SHA" (and its OID) as aliases of "SHA-1". So, either we list all these aliases here, or we only put the standard names here and "canonicalize" the name when we see one. `sun.security.util.KnownOIDs.findMatch("SHA-1").stdName()` can be used.

The aliases are a PITA. It's a shame there isn't support in the public API to canonicalize the names. But, what I will do is canonicalize the incoming strings from the HTTP server and then we only have to list canonical names in the properties.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Thu Mar 10 16:51:08 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 16:51:08 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently
Message-ID: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>

Please find enclosed a patch that solves an intermittent issue detected by the CancelRequestTest.java

If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled after the Http2Connection has been created the handshake has proceeded, and the response headers to the upgrade have been received, but before the HTTP/2 connection is offered to the HTTP/2 connection pull, the underlying TCP connection might get closed at a time where it won't be noticed immediately, resulting in putting a "dead" HTTP/2 connection in the pool. The next request to the same server will then fail with "ClosedChannelException".

The fix is to check the state of the underlying TCP connection before offering the HTTP/2 connection to the pool, and when retrieving it from the pool, and disabling the "connectionAborter" (which is there to abort the connection in case of connect timeout, or cancellation before connect is done) before offering the connection to the pool as well.

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

Commit messages:
 - 8254786: java/net/httpclient/CancelRequestTest.java failing intermittently

Changes: https://git.openjdk.java.net/jdk/pull/7776/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7776&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254786
  Stats: 60 lines in 3 files changed: 43 ins; 6 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7776.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7776/head:pull/7776

PR: https://git.openjdk.java.net/jdk/pull/7776

From michaelm at openjdk.java.net  Thu Mar 10 16:53:40 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Mar 2022 16:53:40 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <H5SBSVBHiBh7OxKyep6sgBRZrz7ak3R0EDIDUAxaUE8=.0b287e26-08a3-4203-bf29-f63d8fa5fc7f@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <H5SBSVBHiBh7OxKyep6sgBRZrz7ak3R0EDIDUAxaUE8=.0b287e26-08a3-4203-bf29-f63d8fa5fc7f@github.com>
Message-ID: <hvAeujIr0K9BQ24TCTcICyRgdWr2NRSuVnD3Nq0VNDY=.a1f67e7e-28a2-4a74-b922-feea523737ef@github.com>

On Thu, 10 Mar 2022 14:26:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update
>>  - update after first review round
>
> src/java.base/share/classes/java/net/doc-files/net-properties.html line 234:
> 
>> 232:         in the {@code java.security} properties file and currently comprises {@code MD5} and
>> 233:         {@code SHA-1}. If it is still required to use one of these algorithms, then they can be
>> 234:         re-enabled by setting this property to a comma separated list of the algorithm names.</P>
> 
> Can we use "re-enabled" in the property name? To me, the name "enabled" sounds like all enabled algorithms are listed here.

Okay, I'm suggesting "http.auth.digest.reEnabledAlgorithms" now. 
Hopefully we can stick with that.

> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 78:
> 
>> 76:     private static final Set<String> defDisabledAlgs = getDefaultAlgs();
>> 77: 
>> 78:     private static Set<String> getDefaultAlgs() {
> 
> How about rename the method to include "disabled"?

That code is reworked so the method no longer exists

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Thu Mar 10 17:02:27 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 17:02:27 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v2]
In-Reply-To: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
Message-ID: <gOKAJjh9PJJGL5OC1WOl8vC9jBJ_-Bf_iQIBpBR9UdM=.a46cc4bf-02d1-4ab4-a7ac-eb27ba9545bf@github.com>

> Please find enclosed a patch that solves an intermittent issue detected by the CancelRequestTest.java
> 
> If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled after the Http2Connection has been created, and the handshake has proceeded, and the response headers to the upgrade have been received, but before the HTTP/2 connection is offered to the HTTP/2 connection pool, the underlying TCP connection might get closed at a time where it won't be noticed immediately, resulting in putting a "dead" HTTP/2 connection in the pool. The next request to the same server will then fail with "ClosedChannelException".
> 
> The fix is to check the state of the underlying TCP connection before offering the HTTP/2 connection to the pool, and when retrieving it from the pool, and disabling the "connectionAborter" (which is there to abort the connection in case of connect timeout, or cancellation before connect is done) before offering the connection to the pool as well.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Add bug id to CancelRequest test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7776/files
  - new: https://git.openjdk.java.net/jdk/pull/7776/files/a553da94..f5b341d2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7776&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7776&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From naoto at openjdk.java.net  Thu Mar 10 17:03:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Mar 2022 17:03:45 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From dfuchs at openjdk.java.net  Thu Mar 10 17:05:32 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 17:05:32 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
Message-ID: <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>

> Please find enclosed a patch that solves an intermittent issue detected by the CancelRequestTest.java
> 
> If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled after the Http2Connection has been created, and the handshake has proceeded, and the response headers to the upgrade have been received, but before the HTTP/2 connection is offered to the HTTP/2 connection pool, the underlying TCP connection might get closed at a time where it won't be noticed immediately, resulting in putting a "dead" HTTP/2 connection in the pool. The next request to the same server will then fail with "ClosedChannelException".
> 
> The fix is to check the state of the underlying TCP connection before offering the HTTP/2 connection to the pool, and when retrieving it from the pool, and disabling the "connectionAborter" (which is there to abort the connection in case of connect timeout, or cancellation before connect is done) before offering the connection to the pool as well.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Copyright years

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7776/files
  - new: https://git.openjdk.java.net/jdk/pull/7776/files/f5b341d2..619bf54f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7776&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7776&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From dfuchs at openjdk.java.net  Thu Mar 10 17:09:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 17:09:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>
Message-ID: <eFN7SFB4835Ai-NMuO6yzfs0cdy5aM90VdU3qr7ctpQ=.52d046e1-33b6-407f-905f-1ca762f286d7@github.com>

On Thu, 10 Mar 2022 17:00:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment.

Thanks Naoto! I have no objection then.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From mullan at openjdk.java.net  Thu Mar 10 17:45:44 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 10 Mar 2022 17:45:44 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <q6SGsvdwndS2tvOX1auIz-FxGrGFsXwP08S2w-cAnFQ=.45c130e0-feba-47c9-8797-806527a6f214@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <H5SBSVBHiBh7OxKyep6sgBRZrz7ak3R0EDIDUAxaUE8=.0b287e26-08a3-4203-bf29-f63d8fa5fc7f@github.com>
 <q6SGsvdwndS2tvOX1auIz-FxGrGFsXwP08S2w-cAnFQ=.45c130e0-feba-47c9-8797-806527a6f214@github.com>
Message-ID: <G3tftk8H0NVzIpocQ12fYj1xrekKWkYAtoHQXZxkDwI=.ce420962-d788-4309-9a21-0cdc0244b23a@github.com>

On Thu, 10 Mar 2022 16:43:23 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 711:
>> 
>>> 709: # separated list of algorithms to be allowed.
>>> 710: #
>>> 711: jdk.httpdigest.defaultDisabledAlgorithms = MD5, MD-5, SHA1, SHA-1
>> 
>> I haven't seen people using "MD-5". It's also not an alias of "MD5" in our own security providers. On the other hand, we support both "SHA1" and "SHA" (and its OID) as aliases of "SHA-1". So, either we list all these aliases here, or we only put the standard names here and "canonicalize" the name when we see one. `sun.security.util.KnownOIDs.findMatch("SHA-1").stdName()` can be used.
>
> The aliases are a PITA. It's a shame there isn't support in the public API to canonicalize the names. But, what I will do is canonicalize the incoming strings from the HTTP server and then we only have to list canonical names in the properties.

I think it would be more consistent if the namespace of the two properties were the same. For example, consider renaming the security property to "http.auth.digest.disabledAlgorithms". I don't think the "default" word adds anything meaningful.

To avoid any confusion, I think you may also want to add a sentence describing that these algorithms are only disabled when used over HTTP, and not HTTPS.  Because I think technically are they still called HTTP digest authentication schemes even if used over HTTPS.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From achung at openjdk.java.net  Thu Mar 10 17:55:44 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 10 Mar 2022 17:55:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  moved CurrencyNames changes to jdk.localedata

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/fb51cf60..4735722d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00-01

  Stats: 2807 lines in 6 files changed: 693 ins; 1527 del; 587 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765

From cjplummer at openjdk.java.net  Thu Mar 10 19:06:43 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 10 Mar 2022 19:06:43 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 305:

> 303:         {"Thread not suspended", "Thread nicht unterbrochen"},
> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
> 305:         {"Threadgroup name not specified.", "Name der Threadgruppe nicht angegeben."},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 342:

> 340:         {"watch modification of", "\u00C4nderung von {0}.{1} \u00FCberwachen"},
> 341:         {"zz help text",
> 342:              "** Befehlsliste **\nconnectors                -- Listet verf\u00FCgbare Connectors und Transporte in dieser VM auf\n\nrun [class [args]]        -- Startet die Ausf\u00FChrung der Hauptklasse der Anwendung\n\nthreads [threadgroup]     -- Listet Threads auf\nthread <Thread-ID>        -- Legt den Standardthread fest\nsuspend [thread id(s)]    -- Unterbricht Threads (Standard: all)\nresume [thread id(s)]    -- Nimmt Threads wieder auf (Standard: all)\nwhere [<Thread-ID> | all] -- Gibt den Stack eines Threads aus\nwherei [<Thread-ID> | all] -- Gibt den Stack eines Threads mit PC-Informationen aus\nup [n frames]             -- Verschiebt den Stack eines Threads nach oben\ndown [n frames]             -- Verschiebt den Stack eines Threads nach unten\nkill <Thread-ID> <Ausdruck>   -- Bricht einen Thread mit dem angegebenen Ausnahmeobjekt ab\ninterrupt <Thread-ID>     -- Unterbricht einen Thread\n\nprint <Ausdruck>              -- Gibt den Wert eines Ausdrucks aus\ndump <A
 usdruck>               -- Gibt alle Objektinformationen aus\neval <Ausdruck>               -- Bewertet einen Ausdruck (wie \"print\")\nset <lvalue> = <Ausdruck>     -- Weist einem Feld/einer Variablen/einem Arrayelement einen neuen Wert zu\nlocals                    -- Gibt alle lokalen Variablen im aktuellen Stackframe aus\n\nclasses                   -- Listet derzeit bekannte Klassen auf\nclass <Klassen-ID>          -- Zeigt Details einer benannten Klasse an\nmethods <Klassen-ID>        -- Listet die Methoden einer Klasse auf\nfields <Klassen-ID>        -- Listet die Felder einer Klasse auf\n\nthreadgroups              -- Listet Threadgruppen auf\nthreadgroup <Name>        -- Legt die aktuelle Threadgruppe fest\n\nstop [go|thread] [<thread_id>] <at|in> <Position>\n                          -- Legt einen Breakpoint fest\n                          -- Wenn Sie keine Optionen angeben, wird die aktuelle Breakpoint-Liste ausgegeben\n                          -- Wenn Sie \"go\" angeben,
  wird der Vorgang nach dem Stoppen sofort wiederaufgenommen\n                          -- Wenn Sie \"thread\" angeben, wird nur der Thread unterbrochen, in dem gestoppt wurde\n                          -- Wenn Sie weder \"go\" noch \"thread\" angeben, werden alle Threads unterbrochen\n                          -- Wenn Sie eine ganzzahlige <thread_id> angeben, wird der Vorgang nur im angegebenen Thread gestoppt\n                          -- \"at\" und \"in\" haben die gleiche Bedeutung\n                          -- <Position> kann eine Zeilennummer oder eine Methode sein:\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<Methode>[(argument_type,...)]\nclear <class id>.<Methode>[(argument_type,...)]\n                          -- L\u00F6scht einen Breakpoint in einer Methode\nclear <Klassen-ID>:<Zeile>   -- L\u00F6scht einen Breakpoint bei einer Zeile\nclear                     -- Listet Breakpoints auf\ncatch [uncaught|caught|all] <Kl
 assen-ID>|<Klassenmuster>\n                          -- Break bei der angegebenen Ausnahme\nignore [uncaught|caught|all] <Klassen-ID>|<Klassenmuster>\n                          -- Bricht \"catch\" f\u00FCr die angegebene Ausnahme ab\nwatch [access|all] <Klassen-ID>.<Feldname>\n                          -- \u00DCberwacht Zugriffe/\u00C4nderungen eines Feldes\nunwatch [access|all] <Klassen-ID>.<Feldname>\n                          -- Hebt die \u00DCberwachung der Zugriffe/\u00C4nderungen eines Feldes auf\ntrace [go] methods [thread]\n                          -- Verfolgt Methodenstarts und -beendigungen.\n                          -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\ntrace [go] method exit | exits [thread]\n                          -- Verfolgt die Beendigung der aktuellen Methode oder die Beendigungen aller Methoden\n                          -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\nuntrace [methods]         -- Stoppt 
 das Tracing von Methodenstarts und/oder -beendigungen\nstep                      -- F\u00FChrt die aktuelle Zeile aus\nstep up                   -- Ausf\u00FChren, bis die aktuelle Methode an den Aufrufer zur\u00FCckgegeben wird\nstepi                     -- F\u00FChrt die aktuelle Anweisung aus\nnext                      -- Eine Zeile weiter (Aufrufe auslassen)\ncont                      -- Setzt die Ausf\u00FChrung ab dem Breakpoint fort\n\nlist [line number|method] -- Gibt den Quellcode aus\nuse (or sourcepath) [source file path]\n                          -- Zeigt den Quellpfad an oder \u00E4ndert diesen\nexclude [<Klassenmuster>, ... | \"none\"]\n                          -- Meldet keine Schritt- oder Methodenereignisse f\u00FCr angegebene Klassen\nclasspath                 -- Gibt Classpath-Informationen aus der Ziel-VM aus\n\nmonitor <Befehl>         -- F\u00FChrt bei jedem Programmstopp einen Befehl aus\nmonitor                   -- Listet Monitore auf\nunmonitor <Monitornum
 mer>      -- L\u00F6scht einen Monitor\nread <Dateiname>           -- Liest eine Befehlsdatei und f\u00FChrt diese aus\n\nlock <Ausdruck>               -- Gibt Sperrinformationen f\u00FCr ein Objekt aus\nthreadlocks [thread id]   -- Gibt Sperrinformationen f\u00FCr einen Thread aus\n\npop                       -- Holt den Stack bis zum aktuellen Frame (einschlie\u00DFlich)\nreenter                   -- Wie \"pop\", aber der aktuelle Frame wird wieder eingegeben\nredefine <Klassen-ID> <Klassendateiname>\n                          -- Definiert den Code f\u00FCr eine Klasse neu\n\ndisablegc <Ausdruck>          -- Verhindert die Garbage Collection eines Objekts\nenablegc <Ausdruck>          -- L\u00E4sst die Garbage Collection eines Objekts zu\n\n!!                        -- Wiederholt den letzten Befehl\n<n> <Befehl>             -- Wiederholt einen Befehl n-mal\nrepeat                    -- Zeigt an, ob die Wiederholung durch leeren Befehl im GDB-Stil aktiviert ist\nrepeat <on|off>    
        -- Aktiviert/deaktiviert die Wiederholung im GDB-Stil\n# <Befehl>               -- Verwerfen (kein Vorgang)\nhelp (oder ?)               -- Listet Befehle auf\ndbgtrace [flag]           -- Identisch mit der Befehlszeilenoption \"dbgtrace\"\nversion                   -- Gibt Versionsinformationen aus\nexit (oder quit)            -- Beendet den Debugger\n\n<Klassen-ID>: Ein vollst\u00E4ndiger Klassenname mit Package-Qualifiers\n<Klassenmuster>: Ein Klassenname mit einem Platzhalter am Anfang oder Ende (\"*\")\n<Thread-ID>: Threadnummer aus dem Befehl \"threads\"\n<Ausdruck>: Ein Ausdruck der Java(TM)-Programmiersprache.\nDer Gro\u00DFteil der g\u00E4ngigen Syntax wird unterst\u00FCtzt.\n\nStartbefehle k\u00F6nnen in \"jdb.ini\" oder \".jdbrc\" abgelegt werden\nin user.home oder user.dir"},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305:

> 303:         {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"},
> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
> 305:         {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"},

I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 342:

> 340:         {"watch modification of", "{0}.{1}\u306E\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1"},
> 341:         {"zz help text",
> 342:              "** \u30B3\u30DE\u30F3\u30C9\u30FB\u30EA\u30B9\u30C8 **\nconnectors                -- \u3053\u306EVM\u5185\u306E\u4F7F\u7528\u53EF\u80FD\u306A\u30B3\u30CD\u30AF\u30BF\u3068\u30C8\u30E9\u30F3\u30B9\u30DD\u30FC\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\n\nrun [class [args]]        -- \u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u306E\u30E1\u30A4\u30F3\u30FB\u30AF\u30E9\u30B9\u306E\u5B9F\u884C\u3092\u958B\u59CB\u3057\u307E\u3059\n\nthreads [threadgroup]     -- \u30B9\u30EC\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthread <thread id>        -- \u30C7\u30D5\u30A9\u30EB\u30C8\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u8A2D\u5B9A\u3057\u307E\u3059\nsuspend [thread id(s)]    -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nresume [thread id(s)]     -- \u30B9\u30EC\u30C3\u30C9\u3092\u518D\u958B\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nwhere [<thread id> | all]
  -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30C0\u30F3\u30D7\u3057\u307E\u3059\nwherei [<thread id> | all]-- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092pc\u60C5\u5831\u3068\u3068\u3082\u306B\u30C0\u30F3\u30D7\u3057\u307E\u3059\nup [n frames]             -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0A\u306B\u79FB\u52D5\u3057\u307E\u3059\ndown [n frames]           -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0B\u306B\u79FB\u52D5\u3057\u307E\u3059\nkill <thread id> <expr>   -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u3067\u30B9\u30EC\u30C3\u30C9\u3092\u5F37\u5236\u7D42\u4E86\u3057\u307E\u3059\ninterrupt <thread id>     -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n\nprint <expr>              -- \u5F0F\u306E\u5024\u3092\u51FA\u529B\u3057\u307E\u3059\ndump <expr>               -- \u3059\u3079\u3066\u306E\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u60C5\u58
 31\u3092\u51FA\u529B\u3057\u307E\u3059\neval <expr>               -- \u5F0F\u3092\u8A55\u4FA1\u3057\u307E\u3059(print\u3068\u540C\u3058)\nset <lvalue> = <expr>     -- \u65B0\u3057\u3044\u5024\u3092\u30D5\u30A3\u30FC\u30EB\u30C9/\u5909\u6570/\u914D\u5217\u8981\u7D20\u306B\u4EE3\u5165\u3057\u307E\u3059\nlocals                    -- \u73FE\u5728\u306E\u30B9\u30BF\u30C3\u30AF\u30FB\u30D5\u30EC\u30FC\u30E0\u5185\u306E\u3059\u3079\u3066\u306E\u30ED\u30FC\u30AB\u30EB\u5909\u6570\u3092\u51FA\u529B\u3057\u307E\u3059\n\nclasses                   -- \u73FE\u5728\u65E2\u77E5\u306E\u30AF\u30E9\u30B9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nclass <class id>          -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u8A73\u7D30\u3092\u8868\u793A\u3057\u307E\u3059\nmethods <class id>        -- \u30AF\u30E9\u30B9\u306E\u30E1\u30BD\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nfields <class id>         -- \u30AF\u30E9\u30B9\u306E\u30D5\u30A3\u30FC\u30EB\u30C9\u3092\u30EA\u30B9\u30C8\u305
 7\u307E\u3059\n\nthreadgroups              -- \u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthreadgroup <name>        -- \u73FE\u5728\u306E\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n\nstop [go|thread] [<thread_id>] <at|in> <location>\n                          -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n                          -- \u30AA\u30D7\u30B7\u30E7\u30F3\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u306E\u73FE\u5728\u306E\u30EA\u30B9\u30C8\u304C\u51FA\u529B\u3055\u308C\u307E\u3059\n                          -- \"go\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u505C\u6B62\u5F8C\u3059\u3050\u306B\u518D\u958B\u3057\u307E\u3059\n                          -- \"thread\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\
 u505C\u6B62\u3057\u305F\u30B9\u30EC\u30C3\u30C9\u306E\u307F\u4E2D\u65AD\u3057\u307E\u3059\n                          -- \"go\"\u3082\"thread\"\u3082\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n                          -- \u6574\u6570\u306E<thread_id>\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u6307\u5B9A\u3055\u308C\u305F\u30B9\u30EC\u30C3\u30C9\u3067\u306E\u307F\u505C\u6B62\u3057\u307E\u3059\n                          -- \"at\"\u3068\"in\"\u306F\u540C\u3058\u610F\u5473\u3092\u6301\u3061\u307E\u3059\n                          -- <location>\u306F\u884C\u756A\u53F7\u307E\u305F\u306F\u30E1\u30BD\u30C3\u30C9\u306B\u3059\u308B\u3053\u3068\u304C\u3067\u304D\u307E\u3059:\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<method>[(argument_type,...)]\nclear <class id>.<method>[(argument_type,...)]\n  
                         -- \u30E1\u30BD\u30C3\u30C9\u5185\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear <class id>:<line>   -- \u884C\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear                     -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\ncatch [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u304C\u767A\u751F\u3057\u305F\u3068\u304D\u306B\u30D6\u30EC\u30FC\u30AF\u3057\u307E\u3059\nignore [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u306E'catch'\u3092\u53D6\u308A\u6D88\u3057\u307E\u3059\nwatch [access|all] <class id>.<field name>\n                          -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u3092\u30A6\u3
 0A9\u30C3\u30C1\u3057\u307E\u3059\nunwatch [access|all] <class id>.<field name>\n                          -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1\u3092\u4E2D\u6B62\u3057\u307E\u3059\ntrace [go] methods [thread]\n                          -- \u30E1\u30BD\u30C3\u30C9\u306E\u5165\u308A\u53E3\u3068\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\u3002\n                          -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\ntrace [go] method exit | exits [thread]\n                          -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u307E\u305F\u306F\u3059\u3079\u3066\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\n                          -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\
 u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\nuntrace [methods]         -- \u30E1\u30BD\u30C3\u30C9\u306E\u958B\u59CB\u307E\u305F\u306F\u7D42\u4E86\u306E\u30C8\u30EC\u30FC\u30B9\u3092\u505C\u6B62\u3057\u307E\u3059\nstep                      -- \u73FE\u5728\u306E\u884C\u3092\u5B9F\u884C\u3057\u307E\u3059\nstep up                   -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u304C\u30E1\u30BD\u30C3\u30C9\u306E\u547C\u51FA\u3057\u5143\u306B\u623B\u308B\u307E\u3067\u5B9F\u884C\u3057\u307E\u3059\nstepi                     -- \u73FE\u5728\u306E\u547D\u4EE4\u3092\u5B9F\u884C\u3057\u307E\u3059\nnext                      -- 1\u884C\u3092\u30B9\u30C6\u30C3\u30D7\u5B9F\u884C\u3057\u307E\u3059(\u547C\u51FA\u3057\u3092\u30B9\u30C6\u30C3\u30D7\u30AA\u30FC\u30D0\u30FC)\ncont                      -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u304B\u3089\u5B9F\u884C\u3092\u7D9A\u884C\u3057\u307E\u3059\n\nlist [line number|method] -- \u30BD\u30FC\u30B9\u30FB\u30B3\u30FC\u30C9\u3092\u
 51FA\u529B\u3057\u307E\u3059\nuse (or sourcepath) [source file path]\n                          -- \u30BD\u30FC\u30B9\u30FB\u30D1\u30B9\u3092\u8868\u793A\u307E\u305F\u306F\u5909\u66F4\u3057\u307E\u3059\nexclude [<class pattern>, ... | \"none\"]\n                          -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u30B9\u30C6\u30C3\u30D7\u3084\u30E1\u30BD\u30C3\u30C9\u30FB\u30A4\u30D9\u30F3\u30C8\u3092\u5831\u544A\u3057\u307E\u305B\u3093\nclasspath                 -- \u30BF\u30FC\u30B2\u30C3\u30C8VM\u304B\u3089\u30AF\u30E9\u30B9\u30D1\u30B9\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\nmonitor <command>         -- \u30D7\u30ED\u30B0\u30E9\u30E0\u304C\u505C\u6B62\u3059\u308B\u305F\u3073\u306B\u30B3\u30DE\u30F3\u30C9\u3092\u5B9F\u884C\u3057\u307E\u3059\nmonitor                   -- \u30E2\u30CB\u30BF\u30FC\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nunmonitor <monitor#>      -- \u30E2\u30CB\u30BF\u30FC\u3092\u524A\u9664\u3057\u307E\u3059\nread <filename>           -- \u30B
 3\u30DE\u30F3\u30C9\u30FB\u30D5\u30A1\u30A4\u30EB\u3092\u8AAD\u307F\u53D6\u3063\u3066\u5B9F\u884C\u3057\u307E\u3059\n\nlock <expr>               -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nthreadlocks [thread id]   -- \u30B9\u30EC\u30C3\u30C9\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\npop                       -- \u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u307E\u3067\u306E\u3059\u3079\u3066\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30DD\u30C3\u30D7\u3057\u307E\u3059\nreenter                   -- pop\u3068\u540C\u3058\u3067\u3059\u304C\u3001\u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u304C\u518D\u5165\u529B\u3055\u308C\u307E\u3059\nredefine <class id> <class file name>\n                          -- \u30AF\u30E9\u30B9\u306E\u30B3\u30FC\u30C9\u3092\u518D\u5B9A\u7FA9\u3057\u307E\u3059\n\ndisablegc <expr>          -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3
 \u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u6291\u5236\u3057\u307E\u3059\nenablegc <expr>           -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3\u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u8A31\u53EF\u3057\u307E\u3059\n\n!!                        -- \u6700\u5F8C\u306E\u30B3\u30DE\u30F3\u30C9\u3092\u7E70\u308A\u8FD4\u3057\u307E\u3059\n<n> <command>             -- \u30B3\u30DE\u30F3\u30C9\u3092n\u56DE\u7E70\u308A\u8FD4\u3057\u307E\u3059\nrepeat                    -- GDB\u5F62\u5F0F\u306E\u7A7A\u306E\u30B3\u30DE\u30F3\u30C9\u306E\u7E70\u8FD4\u3057\u304C\u6709\u52B9\u306B\u306A\u3063\u3066\u3044\u308B\u304B\u3069\u3046\u304B\u3092\u793A\u3057\u307E\u3059\nrepeat <on|off>           -- GDB\u5F62\u5F0F\u306E\u7E70\u8FD4\u3057\u3092\u6709\u52B9/\u7121\u52B9\u306B\u3057\u307E\u3059\n# <command>               -- \u7834\u68C4\u3057\u307E\u3059(\u64CD\u4F5C\u306A\u3057)\nhelp (\u307E\u305F\u306F?)               -- \u30B3\u30DE\u30F3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u3
 07E\u3059\ndbgtrace [flag]           -- dbgtrace\u30B3\u30DE\u30F3\u30C9\u30FB\u30E9\u30A4\u30F3\u30FB\u30AA\u30D7\u30B7\u30E7\u30F3\u3068\u540C\u3058\u3067\u3059\nversion                   -- \u30D0\u30FC\u30B8\u30E7\u30F3\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nexit (\u307E\u305F\u306Fquit)            -- \u30C7\u30D0\u30C3\u30AC\u3092\u7D42\u4E86\u3057\u307E\u3059\n\n<class id>: \u30D1\u30C3\u30B1\u30FC\u30B8\u4FEE\u98FE\u5B50\u3092\u542B\u3080\u5B8C\u5168\u30AF\u30E9\u30B9\u540D\n<class pattern>: \u5148\u982D\u307E\u305F\u306F\u672B\u5C3E\u306E\u30EF\u30A4\u30EB\u30C9\u30AB\u30FC\u30C9('*')\u3092\u542B\u3080\u30AF\u30E9\u30B9\u540D\n<thread id>: 'threads'\u30B3\u30DE\u30F3\u30C9\u3067\u5831\u544A\u3055\u308C\u308B\u30B9\u30EC\u30C3\u30C9\u756A\u53F7\n<expr>: Java(TM)\u30D7\u30ED\u30B0\u30E9\u30DF\u30F3\u30B0\u8A00\u8A9E\u306E\u5F0F\u3002\n\u307B\u3068\u3093\u3069\u306E\u4E00\u822C\u7684\u306A\u69CB\u6587\u304C\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u307E\u3059\u
 3002\n\n\u8D77\u52D5\u30B3\u30DE\u30F3\u30C9\u306F\u3001\"jdb.ini\"\u307E\u305F\u306F\".jdbrc\"\u306B\u914D\u7F6E\u3067\u304D\u307E\u3059\n(user.home\u307E\u305F\u306Fuser.dir\u5185)"},

Also as part of #7687 there is a new entry for the `threadgroup` command without any argument. This used to produce the "Threadgroup name not specified" error message which is I mentioned above was removed. It now has supported functionality, so there should be two `threadgroup` entries:

             "threadgroup <name>        -- set current threadgroup to <name>\n" +
             "threadgroup               -- set current threadgroup back to the top level threadgroup\n" +

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 305:

> 303:         {"Thread not suspended", "\u672A\u6302\u8D77\u7EBF\u7A0B"},
> 304:         {"thread group number description name", "{0,number,integer}\u3002{1} {2}"},
> 305:         {"Threadgroup name not specified.", "\u672A\u6307\u5B9A\u7EBF\u7A0B\u7EC4\u540D\u3002"},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 342:

> 340:         {"watch modification of", "\u76D1\u89C6{0}.{1}\u7684\u4FEE\u6539"},
> 341:         {"zz help text",
> 342:              "** \u547D\u4EE4\u5217\u8868 **\nconnectors                -- \u5217\u51FA\u6B64 VM \u4E2D\u53EF\u7528\u7684\u8FDE\u63A5\u5668\u548C\u4F20\u8F93\n\nrun [class [args]]        -- \u5F00\u59CB\u6267\u884C\u5E94\u7528\u7A0B\u5E8F\u7684\u4E3B\u7C7B\n\nthreads [threadgroup]     -- \u5217\u51FA\u7EBF\u7A0B\nthread <thread id>        -- \u8BBE\u7F6E\u9ED8\u8BA4\u7EBF\u7A0B\nsuspend [thread id(s)]    -- \u6302\u8D77\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nresume [thread id(s)]     -- \u6062\u590D\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nwhere [<thread id> | all] -- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808\nwherei [<thread id> | all]-- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808, \u4EE5\u53CA pc \u4FE1\u606F\nup [n frames]             -- \u4E0A\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\ndown [n frames]           -- \u4E0B\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\nkill <thread id> <expr>   -- \u7EC8\u6B62\u5177\u6709\u7ED9\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u5BF9\u8C61\u7684\u7EBF\u7A0B
 \ninterrupt <thread id>     -- \u4E2D\u65AD\u7EBF\u7A0B\n\nprint <expr>              -- \u8F93\u51FA\u8868\u8FBE\u5F0F\u7684\u503C\ndump <expr>               -- \u8F93\u51FA\u6240\u6709\u5BF9\u8C61\u4FE1\u606F\neval <expr>               -- \u5BF9\u8868\u8FBE\u5F0F\u6C42\u503C (\u4E0E print \u76F8\u540C)\nset <lvalue> = <expr>     -- \u5411\u5B57\u6BB5/\u53D8\u91CF/\u6570\u7EC4\u5143\u7D20\u5206\u914D\u65B0\u503C\nlocals                    -- \u8F93\u51FA\u5F53\u524D\u5806\u6808\u5E27\u4E2D\u7684\u6240\u6709\u672C\u5730\u53D8\u91CF\n\nclasses                   -- \u5217\u51FA\u5F53\u524D\u5DF2\u77E5\u7684\u7C7B\nclass <class id>          -- \u663E\u793A\u5DF2\u547D\u540D\u7C7B\u7684\u8BE6\u7EC6\u8D44\u6599\nmethods <class id>        -- \u5217\u51FA\u7C7B\u7684\u65B9\u6CD5\nfields <class id>         -- \u5217\u51FA\u7C7B\u7684\u5B57\u6BB5\n\nthreadgroups              -- \u5217\u51FA\u7EBF\u7A0B\u7EC4\nthreadgroup <name>        -- \u8BBE\u7F6E\u5F53\u524D\u7EBF\u7A0B\u7EC4\n\nstop [go|
 thread] [<thread_id>] <at|in> <location>\n                          -- \u8BBE\u7F6E\u65AD\u70B9\n                          -- \u5982\u679C\u672A\u63D0\u4F9B\u4EFB\u4F55\u9009\u9879\uFF0C\u5219\u5C06\u6253\u5370\u5F53\u524D\u65AD\u70B9\u5217\u8868\n                          -- \u5982\u679C\u6307\u5B9A \"go\"\uFF0C\u5219\u5728\u505C\u6B62\u540E\u7ACB\u5373\u6062\u590D\n                          -- \u5982\u679C\u6307\u5B9A \"thread\"\uFF0C\u5219\u4EC5\u6302\u8D77\u5728\u5176\u4E2D\u505C\u6B62\u7684\u7EBF\u7A0B\n                          -- \u5982\u679C\u65E2\u672A\u6307\u5B9A \"go\" \u4E5F\u672A\u6307\u5B9A \"thread\"\uFF0C\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\n                          -- \u5982\u679C\u6307\u5B9A\u4EE5\u6574\u6570\u8868\u793A\u7684 <thread_id>\uFF0C\u5219\u4EC5\u5728\u6307\u5B9A\u7684\u7EBF\u7A0B\u4E2D\u505C\u6B62\n                          -- \"at\" \u548C \"in\" \u7684\u542B\u4E49\u76F8\u540C\n                          -- <location> \u53EF\u4EE5\u662F\u884C\u53
 F7\u6216\u65B9\u6CD5\uFF1A\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<method>[(argument_type,...)]\nclear <class id>.<method>[(argument_type,...)]\n                          -- \u6E05\u9664\u65B9\u6CD5\u4E2D\u7684\u65AD\u70B9\nclear <class id>:<line>   -- \u6E05\u9664\u884C\u4E2D\u7684\u65AD\u70B9\nclear                     -- \u5217\u51FA\u65AD\u70B9\ncatch [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u51FA\u73B0\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u65F6\u4E2D\u65AD\nignore [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF, \u53D6\u6D88 'catch'\nwatch [access|all] <class id>.<field name>\n                          -- \u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u8BBF\u95EE/\u4FEE\u6539\nunwatch [access|all] <class id>.<field name>\n                          -- \u505C\u6B62\u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u
 8BBF\u95EE/\u4FEE\u6539\ntrace [go] methods [thread]\n                          -- \u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C\u9000\u51FA\u3002\n                          -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\ntrace [go] method exit | exits [thread]\n                          -- \u8DDF\u8E2A\u5F53\u524D\u65B9\u6CD5\u7684\u9000\u51FA, \u6216\u8005\u6240\u6709\u65B9\u6CD5\u7684\u9000\u51FA\n                          -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\nuntrace [methods]         -- \u505C\u6B62\u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C/\u6216\u9000\u51FA\nstep                      -- \u6267\u884C\u5F53\u524D\u884C\nstep up                   -- \u4E00\u76F4\u6267\u884C, \u76F4\u5230\u5F53\u524D\u65B9\u6CD5\u8FD4\u56DE\u5230\u5176\u8C03\u7528\u65B9\nstepi                     -- \u6267\u884C\u5F53\u524D\u6307\u4EE4\n\u4E0B\u4E00\u6B65                      -- \u6B65\u8FDB\u4E00\u884C (\u6B65\u8FC7\u
 8C03\u7528)\ncont                      -- \u4ECE\u65AD\u70B9\u5904\u7EE7\u7EED\u6267\u884C\n\nlist [line number|method] -- \u8F93\u51FA\u6E90\u4EE3\u7801\nuse (\u6216 sourcepath) [source file path]\n                          -- \u663E\u793A\u6216\u66F4\u6539\u6E90\u8DEF\u5F84\nexclude [<class pattern>, ... | \"none\"]\n                          -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u7C7B, \u4E0D\u62A5\u544A\u6B65\u9AA4\u6216\u65B9\u6CD5\u4E8B\u4EF6\nclasspath                 -- \u4ECE\u76EE\u6807 VM \u8F93\u51FA\u7C7B\u8DEF\u5F84\u4FE1\u606F\n\nmonitor <command>         -- \u6BCF\u6B21\u7A0B\u5E8F\u505C\u6B62\u65F6\u6267\u884C\u547D\u4EE4\nmonitor                   -- \u5217\u51FA\u76D1\u89C6\u5668\nunmonitor <monitor#>      -- \u5220\u9664\u76D1\u89C6\u5668\nread <filename>           -- \u8BFB\u53D6\u5E76\u6267\u884C\u547D\u4EE4\u6587\u4EF6\n\nlock <expr>               -- \u8F93\u51FA\u5BF9\u8C61\u7684\u9501\u4FE1\u606F\nthreadlocks [thread id]   -- \u8F93\u51FA\u7EBF\u7A0B\u7684\u9501
 \u4FE1\u606F\n\npop                       -- \u901A\u8FC7\u5F53\u524D\u5E27\u51FA\u6808, \u4E14\u5305\u542B\u5F53\u524D\u5E27\nreenter                   -- \u4E0E pop \u76F8\u540C, \u4F46\u91CD\u65B0\u8FDB\u5165\u5F53\u524D\u5E27\nredefine <class id> <class file name>\n                          -- \u91CD\u65B0\u5B9A\u4E49\u7C7B\u7684\u4EE3\u7801\n\ndisablegc <expr>          -- \u7981\u6B62\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\nenablegc <expr>           -- \u5141\u8BB8\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\n\n!!                        -- \u91CD\u590D\u6267\u884C\u6700\u540E\u4E00\u4E2A\u547D\u4EE4\n<n> <command>             -- \u5C06\u547D\u4EE4\u91CD\u590D\u6267\u884C n \u6B21\nrepeat                    -- \u663E\u793A\u662F\u5426\u542F\u7528\u4E86 GDB \u6837\u5F0F\u7684\u7A7A\u547D\u4EE4\u91CD\u590D\nrepeat <on|off>           -- \u542F\u7528/\u7981\u7528 GDB \u6837\u5F0F\u7684\u91CD\u590D\n# <command>               -- \u653E\u5F03 (\u65E0\u64CD\u4F5C)\nhelp (\u6216 ?)     
           -- \u5217\u51FA\u547D\u4EE4\ndbgtrace [flag]           -- \u4E0E dbgtrace \u547D\u4EE4\u884C\u9009\u9879\u76F8\u540C\nversion                   -- \u8F93\u51FA\u7248\u672C\u4FE1\u606F\nexit (\u6216 quit)            -- \u9000\u51FA\u8C03\u8BD5\u5668\n\n<class id>: \u5E26\u6709\u7A0B\u5E8F\u5305\u9650\u5B9A\u7B26\u7684\u5B8C\u6574\u7C7B\u540D\n<class pattern>: \u5E26\u6709\u524D\u5BFC\u6216\u5C3E\u968F\u901A\u914D\u7B26 ('*') \u7684\u7C7B\u540D\n<thread id>: 'threads' \u547D\u4EE4\u4E2D\u62A5\u544A\u7684\u7EBF\u7A0B\u7F16\u53F7\n<expr>: Java(TM) \u7F16\u7A0B\u8BED\u8A00\u8868\u8FBE\u5F0F\u3002\n\u652F\u6301\u5927\u591A\u6570\u5E38\u89C1\u8BED\u6CD5\u3002\n\n\u53EF\u4EE5\u5C06\u542F\u52A8\u547D\u4EE4\u7F6E\u4E8E \"jdb.ini\" \u6216 \".jdbrc\" \u4E2D\n\u4F4D\u4E8E user.home \u6216 user.dir \u4E2D"},

Same comment here as mentioned in TTYResources_ja.java.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From naoto at openjdk.java.net  Thu Mar 10 19:54:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Mar 2022 19:54:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <oMFrgMwp9G7NK7ODUrjTKrPIFUgFnperV1nrSzNBU_A=.4014965c-a571-40a9-8ed2-40559c24fadb@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

No need for these lines in each localized files, as English bundle contains them.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

Same here with `de` bundle.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

and here.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From zgu at openjdk.java.net  Thu Mar 10 21:19:03 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 10 Mar 2022 21:19:03 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in various
 places
Message-ID: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>

Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.

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

Commit messages:
 - Fix
 - 8282978: Wrong parameter passed to GetStringXXXChars in various places

Changes: https://git.openjdk.java.net/jdk/pull/7779/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7779&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282978
  Stats: 22 lines in 9 files changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7779.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7779/head:pull/7779

PR: https://git.openjdk.java.net/jdk/pull/7779

From jpai at openjdk.java.net  Fri Mar 11 05:31:45 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 11 Mar 2022 05:31:45 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
 <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
Message-ID: <EMJT-TwQsiq7_1OUpgcIR8F7AQrY3RDy42URrc5E5vE=.dd76e6cf-57b9-428f-94b7-caa8c92b27db@github.com>

On Thu, 10 Mar 2022 17:05:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find enclosed a patch that solves an intermittent issue detected by the CancelRequestTest.java
>> 
>> If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled after the Http2Connection has been created, and the handshake has proceeded, and the response headers to the upgrade have been received, but before the HTTP/2 connection is offered to the HTTP/2 connection pool, the underlying TCP connection might get closed at a time where it won't be noticed immediately, resulting in putting a "dead" HTTP/2 connection in the pool. The next request to the same server will then fail with "ClosedChannelException".
>> 
>> The fix is to check the state of the underlying TCP connection before offering the HTTP/2 connection to the pool, and when retrieving it from the pool, and disabling the "connectionAborter" (which is there to abort the connection in case of connect timeout, or cancellation before connect is done) before offering the connection to the pool as well.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 162:

> 160: 
> 161:         String key = c.key();
> 162:         synchronized(this) {

Hello Daniel, it's not fully clear to me why this synchronized block is needed. Of course, this synchronized block has existed even before this PR, so this isn't a comment about the changes in the PR.
I see that in this synchronized block we are updating the `connections` in one single `putIfAbsent` operation. The `connections` happens to be an instance of `ConcurrentHashMap`. Now, in this PR, additionally we are also including a `c.isOpen()` check in this synchronized block. However, the `Http2Connection#isOpen()` method deals with a `volatile closed` member of the `Http2Connection` and it uses an instance of `Http2Connection` to synchronize on like in the `Http2Connection#shutdown` method. So do you think this synchronization on `Http2ClientImpl` here, while calling `c.isOpen()` is necessary?

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From jpai at openjdk.java.net  Fri Mar 11 05:43:40 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 11 Mar 2022 05:43:40 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
 <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
Message-ID: <N-lCnorVofjTgAkg6BUxbFhXJHZn8yq1P0dQb9e4ZcM=.8b64ce48-4567-49ef-b824-772accdee42e@github.com>

On Thu, 10 Mar 2022 17:05:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find enclosed a patch that solves an intermittent issue detected by the CancelRequestTest.java
>> 
>> If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled after the Http2Connection has been created, and the handshake has proceeded, and the response headers to the upgrade have been received, but before the HTTP/2 connection is offered to the HTTP/2 connection pool, the underlying TCP connection might get closed at a time where it won't be noticed immediately, resulting in putting a "dead" HTTP/2 connection in the pool. The next request to the same server will then fail with "ClosedChannelException".
>> 
>> The fix is to check the state of the underlying TCP connection before offering the HTTP/2 connection to the pool, and when retrieving it from the pool, and disabling the "connectionAborter" (which is there to abort the connection in case of connect timeout, or cancellation before connect is done) before offering the connection to the pool as well.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 170:

> 168:             Http2Connection c1 = connections.putIfAbsent(key, c);
> 169:             if (c1 != null) {
> 170:                 c.setFinalStream();

This comment isn't related to the change in this PR, but is this a typo here? Should it instead be `c1.setFinalStream()`? Reading up on the `finalStream` javadoc in `Http2Connection` this flag indicates that no new streams should be opened on this connection and the connection should be closed once this final stream completes. Is that an accurate understanding?
There's an additional comment on top of this `Http2ClientImpl#offerConnection` which states:
>
> Cache the given connection, if no connection to the same
destination exists. If one exists, then we let the initial stream
complete but allow it to close itself upon completion.
   ...

So if I'm reading that last part correctly in that comment, what it seems to suggest is that we should be allow the initial connection (which is already in cache) to close on completion i.e. mark the `finalStream` flag on the previously cached connection, which in this case is `c1`. So I would expect this to be `c1.setFinalStream()` instead of `c.setFinalStream()`.

Am I misunderstanding this code and comments?

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From dfuchs at openjdk.java.net  Fri Mar 11 10:18:46 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 11 Mar 2022 10:18:46 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <EMJT-TwQsiq7_1OUpgcIR8F7AQrY3RDy42URrc5E5vE=.dd76e6cf-57b9-428f-94b7-caa8c92b27db@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
 <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
 <EMJT-TwQsiq7_1OUpgcIR8F7AQrY3RDy42URrc5E5vE=.dd76e6cf-57b9-428f-94b7-caa8c92b27db@github.com>
Message-ID: <Ax6sP6R-yviqmsVUf7-XVvPW8F3XkXCMPaUYEpJfJ6w=.8fb75e5b-b218-4ba0-ac7c-942248675ccc@github.com>

On Fri, 11 Mar 2022 05:28:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright years
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 162:
> 
>> 160: 
>> 161:         String key = c.key();
>> 162:         synchronized(this) {
> 
> Hello Daniel, it's not fully clear to me why this synchronized block is needed. Of course, this synchronized block has existed even before this PR, so this isn't a comment about the changes in the PR.
> I see that in this synchronized block we are updating the `connections` in one single `putIfAbsent` operation. The `connections` happens to be an instance of `ConcurrentHashMap`. Now, in this PR, additionally we are also including a `c.isOpen()` check in this synchronized block. However, the `Http2Connection#isOpen()` method deals with a `volatile closed` member of the `Http2Connection` and it uses an instance of `Http2Connection` (i.e. a different object monitor) to synchronize on when updating the `closed` member, like in the `Http2Connection#shutdown` method. So do you think this synchronization on `Http2ClientImpl` here, while calling `c.isOpen()` is necessary?

I'm not completely sure of the purpose of the synchronized block here - but I'd rather not change this in this PR (and I'd rather not change it at all unless it proves to cause issues). As for the second check for isOpen() - I included it here because 1. the check is cheap, and 2. since there is a synchronized block - some time may have elapsed waiting for the lock - so rechecking here before putting the connection into the pool would save adding a dead connection to the pool.

> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 170:
> 
>> 168:             Http2Connection c1 = connections.putIfAbsent(key, c);
>> 169:             if (c1 != null) {
>> 170:                 c.setFinalStream();
> 
> This comment isn't related to the change in this PR, but is this a typo here? Should it instead be `c1.setFinalStream()`? Reading up on the `finalStream` javadoc in `Http2Connection` this flag indicates that no new streams should be opened on this connection and the connection should be closed once this final stream completes. Is that an accurate understanding?
> There's an additional comment on top of this `Http2ClientImpl#offerConnection` which states:
>>
>> Cache the given connection, if no connection to the same
> destination exists. If one exists, then we let the initial stream
> complete but allow it to close itself upon completion.
>    ...
> 
> So if I'm reading that last part correctly in that comment, what it seems to suggest is that we should be allow the initial connection (which is already in cache) to close on completion i.e. mark the `finalStream` flag on the previously cached connection, which in this case is `c1`. So I would expect this to be `c1.setFinalStream()` instead of `c.setFinalStream()`.
> 
> Am I misunderstanding this code and comments?

It's not a typo: we want only one Http2Connection of the same type to a given server in the pool (the key encodes the connection type). putIfAbsent returns the previous connection. The logic is to close the *new* connection after the first exchange completes. In other words: the first connection that gets into the pool wins. Keep in mind that the Http2Connection pool is very different to the HTTP/1.1 connection pool. Because HTTP/2 supports multiplexing, Http2Connection stay in the pool until they are closed - the pool contains *active* connections (whereas in HTTP/1.1 it contains *idle* connections).

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From jpai at openjdk.java.net  Fri Mar 11 10:28:46 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 11 Mar 2022 10:28:46 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <Ax6sP6R-yviqmsVUf7-XVvPW8F3XkXCMPaUYEpJfJ6w=.8fb75e5b-b218-4ba0-ac7c-942248675ccc@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
 <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
 <EMJT-TwQsiq7_1OUpgcIR8F7AQrY3RDy42URrc5E5vE=.dd76e6cf-57b9-428f-94b7-caa8c92b27db@github.com>
 <Ax6sP6R-yviqmsVUf7-XVvPW8F3XkXCMPaUYEpJfJ6w=.8fb75e5b-b218-4ba0-ac7c-942248675ccc@github.com>
Message-ID: <fGqjQBOSU4QskvEMcrwU4EuzAkof7qvC6xVxvWqjecg=.02188139-ff6a-479f-b362-97cdd5d06628@github.com>

On Fri, 11 Mar 2022 10:12:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 170:
>> 
>>> 168:             Http2Connection c1 = connections.putIfAbsent(key, c);
>>> 169:             if (c1 != null) {
>>> 170:                 c.setFinalStream();
>> 
>> This comment isn't related to the change in this PR, but is this a typo here? Should it instead be `c1.setFinalStream()`? Reading up on the `finalStream` javadoc in `Http2Connection` this flag indicates that no new streams should be opened on this connection and the connection should be closed once this final stream completes. Is that an accurate understanding?
>> There's an additional comment on top of this `Http2ClientImpl#offerConnection` which states:
>>>
>>> Cache the given connection, if no connection to the same
>> destination exists. If one exists, then we let the initial stream
>> complete but allow it to close itself upon completion.
>>    ...
>> 
>> So if I'm reading that last part correctly in that comment, what it seems to suggest is that we should be allow the initial connection (which is already in cache) to close on completion i.e. mark the `finalStream` flag on the previously cached connection, which in this case is `c1`. So I would expect this to be `c1.setFinalStream()` instead of `c.setFinalStream()`.
>> 
>> Am I misunderstanding this code and comments?
>
> It's not a typo: we want only one Http2Connection of the same type to a given server in the pool (the key encodes the connection type). putIfAbsent returns the previous connection. The logic is to close the *new* connection after the first exchange completes. In other words: the first connection that gets into the pool wins. Keep in mind that the Http2Connection pool is very different to the HTTP/1.1 connection pool. Because HTTP/2 supports multiplexing, Http2Connection stay in the pool until they are closed - the pool contains *active* connections (whereas in HTTP/1.1 it contains *idle* connections).

Thank you - that helped.

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From jpai at openjdk.java.net  Fri Mar 11 10:36:38 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 11 Mar 2022 10:36:38 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <Ax6sP6R-yviqmsVUf7-XVvPW8F3XkXCMPaUYEpJfJ6w=.8fb75e5b-b218-4ba0-ac7c-942248675ccc@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
 <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
 <EMJT-TwQsiq7_1OUpgcIR8F7AQrY3RDy42URrc5E5vE=.dd76e6cf-57b9-428f-94b7-caa8c92b27db@github.com>
 <Ax6sP6R-yviqmsVUf7-XVvPW8F3XkXCMPaUYEpJfJ6w=.8fb75e5b-b218-4ba0-ac7c-942248675ccc@github.com>
Message-ID: <dmw0tRSI4uENSoSYvnZ65rQ_AjWy6WbAJcqyQF9bJFM=.d04959a6-fee9-4e33-8366-ffc2f3a4ccfd@github.com>

On Fri, 11 Mar 2022 10:07:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 162:
>> 
>>> 160: 
>>> 161:         String key = c.key();
>>> 162:         synchronized(this) {
>> 
>> Hello Daniel, it's not fully clear to me why this synchronized block is needed. Of course, this synchronized block has existed even before this PR, so this isn't a comment about the changes in the PR.
>> I see that in this synchronized block we are updating the `connections` in one single `putIfAbsent` operation. The `connections` happens to be an instance of `ConcurrentHashMap`. Now, in this PR, additionally we are also including a `c.isOpen()` check in this synchronized block. However, the `Http2Connection#isOpen()` method deals with a `volatile closed` member of the `Http2Connection` and it uses an instance of `Http2Connection` (i.e. a different object monitor) to synchronize on when updating the `closed` member, like in the `Http2Connection#shutdown` method. So do you think this synchronization on `Http2ClientImpl` here, while calling `c.isOpen()` is necessary?
>
> I'm not completely sure of the purpose of the synchronized block here - but I'd rather not change this in this PR (and I'd rather not change it at all unless it proves to cause issues). As for the second check for isOpen() - I included it here because 1. the check is cheap, and 2. since there is a synchronized block - some time may have elapsed waiting for the lock - so rechecking here before putting the connection into the pool would save adding a dead connection to the pool.

Sounds fine to me. One last question - I suspect you didn't include the additional `c.finalStream()` within this synchronized block because that call is relatively expensive (with `finalStream()` being `synchronized`)?

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From alanb at openjdk.java.net  Fri Mar 11 10:37:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 11 Mar 2022 10:37:40 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
Message-ID: <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>

On Thu, 10 Mar 2022 21:12:46 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.

The changes to the usages in src/java.base look okay.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7779

From dfuchs at openjdk.java.net  Fri Mar 11 10:37:40 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 11 Mar 2022 10:37:40 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
Message-ID: <EXgjOMjqS6Fc5W-zNB0VyC1bkR5mGdvzvGS1J03ube4=.e80155a9-b469-45d0-b3b5-5d2c0d099965@github.com>

On Thu, 10 Mar 2022 21:12:46 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.

Marked as reviewed by dfuchs (Reviewer).

The `libnet` changes look good to me - but please get someone from the client team to approve the client changes before integrating (though I didn't see any issue with these).

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

PR: https://git.openjdk.java.net/jdk/pull/7779

From jpai at openjdk.java.net  Fri Mar 11 10:39:46 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 11 Mar 2022 10:39:46 GMT
Subject: RFR: 8277969: HttpClient SelectorManager shuts down when custom
 Executor rejects a task [v3]
In-Reply-To: <cQASI85evCubOTVuUDuEG5UlMPSsp9svsC5XLQH_FHQ=.3a336795-cd96-4acf-8f19-e2e04d3da4ae@github.com>
References: <NvdqW8ayaB1JaCkrHE-7PW8A2Q0G7HI58bCFedtA-Jo=.c22f7366-cdf3-42a4-8e99-bb2ba693a9da@github.com>
 <cQASI85evCubOTVuUDuEG5UlMPSsp9svsC5XLQH_FHQ=.3a336795-cd96-4acf-8f19-e2e04d3da4ae@github.com>
Message-ID: <Nm7HlSdMbLU5Bl_xXXkaE3H1z8sGINvdkqwJzYaSaHM=.ec062f93-f7f0-49bb-b4e7-24d0e64de730@github.com>

On Thu, 10 Mar 2022 11:17:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> These changes make sure that pending requests are terminated if the selector manager thread exits due to exceptions.
>> This includes:
>>    1. completing CompletableFutures that were returned to the caller code
>>    2. cancelling requests that are in flight
>>    3. calling onError on BodySubscribers that may not have been completed
>> Note that step 3 is necessary as certain CompletableFutures, such as those returned by `BodySubscribers.ofInputStream`, complete immediately, the operation being eventually completed when the last bite of the response is read. Completing a completable future that is already completed has no effect, this case is handled by completing the BodySubscriber too.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   asserts that acquired == true

Marked as reviewed by jpai (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/7196

From jpai at openjdk.java.net  Fri Mar 11 10:50:44 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 11 Mar 2022 10:50:44 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
 <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
Message-ID: <lSmZSY3Dsqs282hVWHgZ1EltPbzJb2N2mLVY6VkbHbU=.79f0e3cd-f6dd-4a31-82a3-afe9dfc4c6d1@github.com>

On Thu, 10 Mar 2022 17:05:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find enclosed a patch that solves an intermittent issue detected by the CancelRequestTest.java
>> 
>> If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled after the Http2Connection has been created, and the handshake has proceeded, and the response headers to the upgrade have been received, but before the HTTP/2 connection is offered to the HTTP/2 connection pool, the underlying TCP connection might get closed at a time where it won't be noticed immediately, resulting in putting a "dead" HTTP/2 connection in the pool. The next request to the same server will then fail with "ClosedChannelException".
>> 
>> The fix is to check the state of the underlying TCP connection before offering the HTTP/2 connection to the pool, and when retrieving it from the pool, and disabling the "connectionAborter" (which is there to abort the connection in case of connect timeout, or cancellation before connect is done) before offering the connection to the pool as well.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

Marked as reviewed by jpai (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From dfuchs at openjdk.java.net  Fri Mar 11 10:50:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 11 Mar 2022 10:50:44 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <dmw0tRSI4uENSoSYvnZ65rQ_AjWy6WbAJcqyQF9bJFM=.d04959a6-fee9-4e33-8366-ffc2f3a4ccfd@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
 <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
 <EMJT-TwQsiq7_1OUpgcIR8F7AQrY3RDy42URrc5E5vE=.dd76e6cf-57b9-428f-94b7-caa8c92b27db@github.com>
 <Ax6sP6R-yviqmsVUf7-XVvPW8F3XkXCMPaUYEpJfJ6w=.8fb75e5b-b218-4ba0-ac7c-942248675ccc@github.com>
 <dmw0tRSI4uENSoSYvnZ65rQ_AjWy6WbAJcqyQF9bJFM=.d04959a6-fee9-4e33-8366-ffc2f3a4ccfd@github.com>
Message-ID: <bvZRpv3BdK-R3WmMMk5JzQb6Cefrxaj6QQvuEW40-k0=.d218e9ad-3aa6-4837-ad5f-11f7cc164048@github.com>

On Fri, 11 Mar 2022 10:33:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I'm not completely sure of the purpose of the synchronized block here - but I'd rather not change this in this PR (and I'd rather not change it at all unless it proves to cause issues). As for the second check for isOpen() - I included it here because 1. the check is cheap, and 2. since there is a synchronized block - some time may have elapsed waiting for the lock - so rechecking here before putting the connection into the pool would save adding a dead connection to the pool.
>
> Sounds fine to me. One last question - I suspect you didn't include the additional `c.finalStream()` within this synchronized block because that call is relatively expensive (with `finalStream()` being `synchronized`)?

Well - no - I'm not expecting finalStream() to be changed asynchronously while adding the connection to the pool.
setFinalStream() is called at very few places, and a connection is offered to the pool only once.
On the other hand - the underlying TCP connection could be closed any time by the remote peer.

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From duke at openjdk.java.net  Fri Mar 11 10:52:47 2022
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 11 Mar 2022 10:52:47 GMT
Subject: Integrated: JDK-8282354 : Remove dependancy of TestHttpServer,
 HttpTransaction, HttpCallback from open/test/jdk/ tests
In-Reply-To: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
References: <SGsmuBZv3Ib0Ur3qM9G83X2AKv3S-hq9Pn3_feE4vR4=.400504fa-865c-4a9e-849a-f9a770f5026f@github.com>
Message-ID: <m1P25jSqeI8BOMT6eZ7EQYGH3BGSVvX_UsINSIkyk4c=.470837d1-3786-487a-8df9-97a6975a0b54@github.com>

On Thu, 24 Feb 2022 16:01:57 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

> Updated following remaining tests to remove depenedies of TestHttpServer, HttpTransaction, HttpCallback
> open/test/jdk/java/net/ProxySelector/LoopbackAddresses.java
> open/test/jdk/java/net/ProxySelector/ProxyTest.java
> open/test/jdk/java/net/URL/PerConnectionProxy.java
> open/test/jdk/java/net/URLConnection/B5052093.java
> open/test/jdk/sun/net/www/AuthHeaderTest.java
> open/test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java

This pull request has now been integrated.

Changeset: 95ca9443
Author:    Mahendra Chhipa <mahendra.chhipa at oracle.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/95ca94436d12974d98b1b999f9cc8408d64cbe3c
Stats:     1714 lines in 12 files changed: 203 ins; 1408 del; 103 mod

8282354: Remove dependancy of TestHttpServer, HttpTransaction, HttpCallback from open/test/jdk/ tests

Reviewed-by: dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/7616

From zgu at openjdk.java.net  Fri Mar 11 13:28:42 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 11 Mar 2022 13:28:42 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
 <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>
Message-ID: <EfGcC-dhLrfyHSVInZVBnAG4kz64UujpJlUw0QyvmPg=.f9f399e1-3de5-4edc-af8d-08b49d087b1e@github.com>

On Fri, 11 Mar 2022 10:33:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.
>
> The changes to the usages in src/java.base look okay.

Thanks, @AlanBateman @dfuch

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

PR: https://git.openjdk.java.net/jdk/pull/7779

From zgu at openjdk.java.net  Fri Mar 11 13:28:42 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 11 Mar 2022 13:28:42 GMT
Subject: Integrated: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
Message-ID: <wEmH-aA323woAamnIrek6fd-j8ewcEWMQysh0tfX9uw=.b540b2b9-1666-4bb7-9f8c-ed2e985a0030@github.com>

On Thu, 10 Mar 2022 21:12:46 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.

This pull request has now been integrated.

Changeset: 0fd09d38
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0fd09d383b9921f26d2d609ab330630a4520325a
Stats:     22 lines in 9 files changed: 0 ins; 0 del; 22 mod

8282978: Wrong parameter passed to GetStringXXXChars in various places

Reviewed-by: alanb, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/7779

From alanb at openjdk.java.net  Fri Mar 11 13:37:44 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 11 Mar 2022 13:37:44 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
 <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>
Message-ID: <WLTY-zcBWgTtbZzyyxKPEiS0LGNXTjOZWbEQf9Rq618=.f2d90293-6b59-44f4-b125-196c4b84c4e1@github.com>

On Fri, 11 Mar 2022 10:33:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Another trivial cleanup to fix the last parameter of `GetStringXXXChars` calls, should be a `jboolean*` instead of a `jboolean`.
>
> The changes to the usages in src/java.base look okay.

> Thanks, @AlanBateman @dfuch

but make sure to get someone from the client libs area to okay the changes in src/java.desktop.

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

PR: https://git.openjdk.java.net/jdk/pull/7779

From weijun at openjdk.java.net  Fri Mar 11 15:32:52 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 11 Mar 2022 15:32:52 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <OJXsIql3eK0cuKV5iLH_tmXrzKQkov7dukuN5CU5FQ4=.fb66f4aa-ff5d-45b9-a6fb-7fcb9c29f5bc@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

The security related changes look fine, except for the year 2021.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From aefimov at openjdk.java.net  Fri Mar 11 16:55:02 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 11 Mar 2022 16:55:02 GMT
Subject: RFR: 8282536: java.net.InetAddress should be a sealed class
Message-ID: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>

The following fix seals the `java.net.InetAddress` class and permits only two implementations - `java.net.Inet4Address` and `java.net.Inet6Address`. 

No issues have been detected by regression and JCK tests.

Links: [JBS](https://bugs.openjdk.java.net/browse/JDK-8282536) [CSR](https://bugs.openjdk.java.net/browse/JDK-8282880)

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

Commit messages:
 - Add qualified Serializable usage with import
 - 8282536: java.net.InetAddress should be a sealed class

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

PR: https://git.openjdk.java.net/jdk/pull/7789

From michaelm at openjdk.java.net  Fri Mar 11 17:31:51 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 11 Mar 2022 17:31:51 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <ukrw7FFQbUztwc27Dxd-5FtZxcCJdcqx7S75lxPX7MU=.908f751a-893c-4817-9511-c52429c937d2@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <anHW0t-4KnemkkaUn-1lr_ogFC8ozGv26Gdi9QR2pUU=.0f6239bd-5585-4130-8a3a-8269943d92f4@github.com>
 <4MHtZOqmeLytUfn0hzSvZtp8KNhLIGyDKUkOcJY1NzY=.4325630b-007c-4f97-bc9d-5d96f891a3c7@github.com>
 <ekXdqzApKo-b3SJ69CbBvhh40C6WqvwjVvklZ88aJBw=.c5634cfa-df63-45d1-aec7-c199725db2d7@github.com>
 <ukrw7FFQbUztwc27Dxd-5FtZxcCJdcqx7S75lxPX7MU=.908f751a-893c-4817-9511-c52429c937d2@github.com>
Message-ID: <G5cNjV9FxXDXxVfbVnjKU-YqULYDgX81HpD9Z704rOM=.64cd21bc-d9f1-4542-aa1e-42e0e095c26f@github.com>

On Mon, 7 Mar 2022 14:41:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> 2nd test of https://datatracker.ietf.org/doc/html/rfc7616#section-3.9 is on this algorithm, but it requires UTF-8 charset support and a way to provide a predefined cnonce. If it's not worth modifying our implementation to create a regression test, I think at least we can temporarily hack our own JDK and try on it. And I think it's most likely true that this algorithm is using a different initialization vector as Bernd pointed out.
>
> As https://www.rfc-editor.org/errata_search.php?rfc=7616&rec_status=0 shows, that 2nd test in rfc7616 was wrong in the initial version as it used a truncated version of SHA-512. The real SHA-512/256 algorithm should be used.
> 
> $ jshell
> jshell> import java.security.MessageDigest
> 
> jshell> HexFormat.of().formatHex(MessageDigest.getInstance("SHA-512").digest("J\u00e4s\u00f8n Doe:api at example.org".getBytes("UTF-8")))
> $2 ==> "488869477bf257147b804c45308cd62ac4e25eb717b12b298c79e62dcea254ec5211a6631b181289b4dd8c14890f38f04bff8a388106dabb900c6984ba592b6a"
> 
> jshell> HexFormat.of().formatHex(MessageDigest.getInstance("SHA-512/256").digest("J\u00e4s\u00f8n Doe:api at example.org".getBytes("UTF-8")))
> $3 ==> "793263caabb707a56211940d90411ea4a575adeccb7e360aeb624ed06ece9b0b"

We could put a property in there to seed the random number generator, but I'd prefer not to do that. I will check with a modified JDK that it works with this data though.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Fri Mar 11 17:31:52 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 11 Mar 2022 17:31:52 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <H5SBSVBHiBh7OxKyep6sgBRZrz7ak3R0EDIDUAxaUE8=.0b287e26-08a3-4203-bf29-f63d8fa5fc7f@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <H5SBSVBHiBh7OxKyep6sgBRZrz7ak3R0EDIDUAxaUE8=.0b287e26-08a3-4203-bf29-f63d8fa5fc7f@github.com>
Message-ID: <UmWqYf1Lm5f63c_bhOT8pPRoDHVkUHuKR6g8PpI6pT0=.9e081976-33e8-4d51-aebb-a4c691508097@github.com>

On Thu, 10 Mar 2022 15:02:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update
>>  - update after first review round
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 701:
> 
>> 699:         }
>> 700:         byte[] digest = md.digest();
>> 701:         StringBuilder res = new StringBuilder(digest.length * 2);
> 
> Can we use `HexFormat` to encode the bytes?

The fix will probably be back ported, so I'd prefer not to use HexFormat.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Fri Mar 11 17:37:44 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 11 Mar 2022 17:37:44 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v3]
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <pwieeIUqDWAn8QjkAjnQwLQNoDdd4VLMLRq2bVIhymo=.481dac09-e6f7-4711-82c9-d1e30cac239e@github.com>

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  update after second review round

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7688/files
  - new: https://git.openjdk.java.net/jdk/pull/7688/files/b765d412..3d5ef143

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=01-02

  Stats: 160 lines in 12 files changed: 59 ins; 25 del; 76 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7688.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7688/head:pull/7688

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Fri Mar 11 17:52:45 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 11 Mar 2022 17:52:45 GMT
Subject: RFR: 8282536: java.net.InetAddress should be a sealed class
In-Reply-To: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
References: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
Message-ID: <YODk7OjqGo5e5sSOw97ucNCEup2__0nleazuj6ztxS0=.274afd3a-b8e8-424c-aa83-dea65f605211@github.com>

On Fri, 11 Mar 2022 16:47:46 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The following fix seals the `java.net.InetAddress` class and permits only two implementations - `java.net.Inet4Address` and `java.net.Inet6Address`. 
> 
> No issues have been detected by regression and JCK tests.
> 
> Links: [JBS](https://bugs.openjdk.java.net/browse/JDK-8282536) [CSR](https://bugs.openjdk.java.net/browse/JDK-8282880)

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7789

From michaelm at openjdk.java.net  Fri Mar 11 17:56:57 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 11 Mar 2022 17:56:57 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v3]
In-Reply-To: <pwieeIUqDWAn8QjkAjnQwLQNoDdd4VLMLRq2bVIhymo=.481dac09-e6f7-4711-82c9-d1e30cac239e@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <pwieeIUqDWAn8QjkAjnQwLQNoDdd4VLMLRq2bVIhymo=.481dac09-e6f7-4711-82c9-d1e30cac239e@github.com>
Message-ID: <4NTa_S3wjKURZkVQwjnE_jgnahBrEPqUGtbc5B8aeao=.113cd652-efc5-4f29-a125-1d025b73e338@github.com>

On Fri, 11 Mar 2022 17:37:44 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update after second review round

I still plan to add a couple more tests for UTF-8 encoding and if possible for username hashing

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From prr at openjdk.java.net  Fri Mar 11 18:05:44 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Mar 2022 18:05:44 GMT
Subject: RFR: 8282978: Wrong parameter passed to GetStringXXXChars in
 various places
In-Reply-To: <EfGcC-dhLrfyHSVInZVBnAG4kz64UujpJlUw0QyvmPg=.f9f399e1-3de5-4edc-af8d-08b49d087b1e@github.com>
References: <5CXGspb5JmMAfTBvqIM6lwKqphxffVSdjvOkqtN7oYg=.0ed04b08-bdf0-4339-9180-4101f8b78634@github.com>
 <BNMwHhMjYJEFw30ktYz5mTaPUr3SvoZ9u0mY_Uc_2VY=.e4fd2970-18dc-4e4b-884f-3c1b75eba8f1@github.com>
 <EfGcC-dhLrfyHSVInZVBnAG4kz64UujpJlUw0QyvmPg=.f9f399e1-3de5-4edc-af8d-08b49d087b1e@github.com>
Message-ID: <xKM_Y_GLzpvuafmYj1H9WDytaxfF--poyL0bgphvvVU=.ab0a2a09-709d-4625-be65-e7116979d93c@github.com>

On Fri, 11 Mar 2022 13:23:23 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> The changes to the usages in src/java.base look okay.
>
> Thanks, @AlanBateman @dfuch

@zhengyu123 - why did you ignore the request to wait for a client reviewer ?
Over half the files touched are in client ? Might I ask what tests you ran ?
And as far as I can see this was pushed only 16 hours after the RFR went out so you can hardly claim that you waited .. and this surely wasn't urgent.

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

PR: https://git.openjdk.java.net/jdk/pull/7779

From weijun at openjdk.java.net  Fri Mar 11 18:14:48 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 11 Mar 2022 18:14:48 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v3]
In-Reply-To: <pwieeIUqDWAn8QjkAjnQwLQNoDdd4VLMLRq2bVIhymo=.481dac09-e6f7-4711-82c9-d1e30cac239e@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <pwieeIUqDWAn8QjkAjnQwLQNoDdd4VLMLRq2bVIhymo=.481dac09-e6f7-4711-82c9-d1e30cac239e@github.com>
Message-ID: <Q4c7c8PXFEg-c5AKJVtlTL9lGGHRTyH8Tjzhk1uZf6M=.490aae3d-c10d-4c19-8b3c-2aeecfb4903a@github.com>

On Fri, 11 Mar 2022 17:37:44 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update after second review round

Please remove `src/java.base/share/classes/java/util/.Random.java.swp`.

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 430:

> 428:             algorithm = "MD5";  // The default, accoriding to rfc2069
> 429:         }
> 430:         var oid = KnownOIDs.findMatch(algorithm.toUpperCase(Locale.ROOT));

No need to call `toUpperCase`. `findMatch` already called that. On the other hand, we don't support the name `SHA-512-256`, and if you translate it to stdName here there is no need to do it again in `computeUserhash`.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From weijun at openjdk.java.net  Fri Mar 11 18:14:49 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 11 Mar 2022 18:14:49 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v2]
In-Reply-To: <hvAeujIr0K9BQ24TCTcICyRgdWr2NRSuVnD3Nq0VNDY=.a1f67e7e-28a2-4a74-b922-feea523737ef@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z27KRjrKa3GIjFcu5axf-r0mnMwI0jAhfkpFjO3GCZc=.aa9d8931-2ffe-42c6-b480-e468b1ca6aa8@github.com>
 <H5SBSVBHiBh7OxKyep6sgBRZrz7ak3R0EDIDUAxaUE8=.0b287e26-08a3-4203-bf29-f63d8fa5fc7f@github.com>
 <hvAeujIr0K9BQ24TCTcICyRgdWr2NRSuVnD3Nq0VNDY=.a1f67e7e-28a2-4a74-b922-feea523737ef@github.com>
Message-ID: <EqHVETnP-p7rW1caiOE1JSei9UfBDUAWoJsw8MVQi0c=.612dd1fb-779d-49a8-83c6-0eb922a5d3d3@github.com>

On Thu, 10 Mar 2022 16:50:05 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/doc-files/net-properties.html line 234:
>> 
>>> 232:         in the {@code java.security} properties file and currently comprises {@code MD5} and
>>> 233:         {@code SHA-1}. If it is still required to use one of these algorithms, then they can be
>>> 234:         re-enabled by setting this property to a comma separated list of the algorithm names.</P>
>> 
>> Can we use "re-enabled" in the property name? To me, the name "enabled" sounds like all enabled algorithms are listed here.
>
> Okay, I'm suggesting "http.auth.digest.reEnabledAlgorithms" now. 
> Hopefully we can stick with that.

Property name not updated yet.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From wetmore at openjdk.java.net  Sat Mar 12 01:46:42 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Sat, 12 Mar 2022 01:46:42 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v2]
In-Reply-To: <RTMIZVUctVVu5k-Pij3U7jtFsLLQIX9a_8qfNwEqD54=.91e76e3f-94d4-4308-8527-3c6e6871475c@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <j4sqdo5vLlBwWSUNCpQEzns9tlaPY2ORgxEtJ7yhmfA=.d9a984be-82c6-4bfa-8632-56ced31828ab@github.com>
 <V1YL5fqQGJDv8Ie_92pze5F52zj_mMdxI6YJnW9s9VE=.75831831-d52c-40ba-aa5c-f1b4a2c92ca0@github.com>
 <aaV94yQvjHRziwGoBRGfgUqzsJl6Wqxgrhvr78ALt-4=.1503e22d-c2aa-4490-9b43-306b186bdc98@github.com>
 <NmGt4etntWHORR90TXqpODCcTAVHlvf_58jcp5gFbBE=.dc5a0e75-d574-4e21-9044-d79f9fb5ee3b@github.com>
 <RTMIZVUctVVu5k-Pij3U7jtFsLLQIX9a_8qfNwEqD54=.91e76e3f-94d4-4308-8527-3c6e6871475c@github.com>
Message-ID: <QSQopAhkHRPocPEBibwS8VlYV1bHJB0RV0jwGKe6hJ4=.0647caba-b07d-476e-90f9-df3edc1972f4@github.com>

On Tue, 8 Mar 2022 15:23:13 GMT, zzambers <duke at openjdk.java.net> wrote:

>>> Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the
>>  process. Is action expected from my side?
>> 
>> One of us needs to get the CSR approved.  Why don't you pull the changes described in:
>> 
>> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html
>> 
>> Assuming you are ok with the updated wording, I can create the CSR and submit.  Once that it approved, then we can get this PR approved and you can integrate. 
>> 
>> Are you at contributor status?
>
> @bradfordwetmore Your changes look good to me. When it comes to wording, I'll let that to native english speaker(s) to judge :) (As I am not native english speaker myself).  I built docs locally and result looks good (also links work), there was just one problem with brace, but I have fixed that.

@zzambers, the CSR was approved yesterday, and is just waiting your integration.  I will sponsor it.

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From jpai at openjdk.java.net  Sat Mar 12 08:06:37 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 12 Mar 2022 08:06:37 GMT
Subject: RFR: 8282536: java.net.InetAddress should be a sealed class
In-Reply-To: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
References: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
Message-ID: <Ey7D4hDf4uOZ5x1aK_EZmNMHtiuAH8f--KXluHAYnwU=.b7adda68-d7a7-43aa-a03e-280578be7540@github.com>

On Fri, 11 Mar 2022 16:47:46 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The following fix seals the `java.net.InetAddress` class and permits only two implementations - `java.net.Inet4Address` and `java.net.Inet6Address`. 
> 
> No issues have been detected by regression and JCK tests.
> 
> Links: [JBS](https://bugs.openjdk.java.net/browse/JDK-8282536) [CSR](https://bugs.openjdk.java.net/browse/JDK-8282880)

Marked as reviewed by jpai (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/7789

From michaelm at openjdk.java.net  Mon Mar 14 10:07:39 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 14 Mar 2022 10:07:39 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
 <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
Message-ID: <aGHdbwho5tW_Q2R6qGPywpUQKjYucFtIUIY_jVplW9w=.e61cda24-f306-4a71-b4d3-7be59f06b897@github.com>

On Thu, 10 Mar 2022 17:05:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find enclosed a patch that solves an intermittent issue detected by the CancelRequestTest.java
>> 
>> If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled after the Http2Connection has been created, and the handshake has proceeded, and the response headers to the upgrade have been received, but before the HTTP/2 connection is offered to the HTTP/2 connection pool, the underlying TCP connection might get closed at a time where it won't be noticed immediately, resulting in putting a "dead" HTTP/2 connection in the pool. The next request to the same server will then fail with "ClosedChannelException".
>> 
>> The fix is to check the state of the underlying TCP connection before offering the HTTP/2 connection to the pool, and when retrieving it from the pool, and disabling the "connectionAborter" (which is there to abort the connection in case of connect timeout, or cancellation before connect is done) before offering the connection to the pool as well.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 155:

> 153:     boolean offerConnection(Http2Connection c) {
> 154:         if (debug.on()) debug.log("offering to the connection pool: %s", c);
> 155:         if (!c.isOpen() || c.finalStream()) {

Is this check for isOpen() not redundant given the same check added inside the synchronized block?

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From duke at openjdk.java.net  Mon Mar 14 10:41:40 2022
From: duke at openjdk.java.net (zzambers)
Date: Mon, 14 Mar 2022 10:41:40 GMT
Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
 [v2]
In-Reply-To: <QSQopAhkHRPocPEBibwS8VlYV1bHJB0RV0jwGKe6hJ4=.0647caba-b07d-476e-90f9-df3edc1972f4@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
 <j4sqdo5vLlBwWSUNCpQEzns9tlaPY2ORgxEtJ7yhmfA=.d9a984be-82c6-4bfa-8632-56ced31828ab@github.com>
 <V1YL5fqQGJDv8Ie_92pze5F52zj_mMdxI6YJnW9s9VE=.75831831-d52c-40ba-aa5c-f1b4a2c92ca0@github.com>
 <aaV94yQvjHRziwGoBRGfgUqzsJl6Wqxgrhvr78ALt-4=.1503e22d-c2aa-4490-9b43-306b186bdc98@github.com>
 <NmGt4etntWHORR90TXqpODCcTAVHlvf_58jcp5gFbBE=.dc5a0e75-d574-4e21-9044-d79f9fb5ee3b@github.com>
 <RTMIZVUctVVu5k-Pij3U7jtFsLLQIX9a_8qfNwEqD54=.91e76e3f-94d4-4308-8527-3c6e6871475c@github.com>
 <QSQopAhkHRPocPEBibwS8VlYV1bHJB0RV0jwGKe6hJ4=.0647caba-b07d-476e-90f9-df3edc1972f4@github.com>
Message-ID: <hY4otPUEpgv3CCoIYacYZxveG4EYDwn85MEUKFBMpo0=.2b5fd4f1-aa2e-436f-9b29-118223e17bf5@github.com>

On Sat, 12 Mar 2022 01:43:16 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> @bradfordwetmore Your changes look good to me. When it comes to wording, I'll let that to native english speaker(s) to judge :) (As I am not native english speaker myself).  I built docs locally and result looks good (also links work), there was just one problem with brace, but I have fixed that.
>
> @zzambers, the CSR was approved yesterday, and is just waiting your integration.  I will sponsor it.

@bradfordwetmore, thanks

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From ccleary at openjdk.java.net  Mon Mar 14 11:22:51 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 14 Mar 2022 11:22:51 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v2]
In-Reply-To: <Kkb44b46Xq1zd6lFgllDvKFVAW_gPbyJGSd7jMUNTZc=.3d600e2b-bbc9-4abd-8d1e-48d4f19b252b@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <p9reBBHP0p7l4xxPRfKFKl_At-RLmVS2eHRdevXZtH0=.9d03c1cf-b752-4286-bc48-5447a768b976@github.com>
 <Kkb44b46Xq1zd6lFgllDvKFVAW_gPbyJGSd7jMUNTZc=.3d600e2b-bbc9-4abd-8d1e-48d4f19b252b@github.com>
Message-ID: <4vKLmfxNMtLaj6xKZONU6v6WtQRjc1BXyYBkcMmrt8k=.79f648b2-8619-454d-9419-b70affadc955@github.com>

On Mon, 7 Mar 2022 12:28:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8263031: Tidied up import statements
>
> test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 176:
> 
>> 174:             ContinuationFrame cf = new ContinuationFrame(streamid, HeaderFrame.END_HEADERS, encodedHeaders);
>> 175: 
>> 176:             try {
> 
> It would be good to have a test-case that creates 2 continuation frames too.

Good idea yes, to check that the repeat continuation still behaves as expected. Should hopefully be straight forward to create another test case.

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From michaelm at openjdk.java.net  Mon Mar 14 10:35:26 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 14 Mar 2022 10:35:26 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v4]
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <9jBMw5ABn13lB9KlsPvMqEdvhzRQrQBz-yhKFitb-z0=.cfbf5fdf-77dd-4723-874d-6abd928f909f@github.com>

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:

 - update after third review round
 - removed swp file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7688/files
  - new: https://git.openjdk.java.net/jdk/pull/7688/files/3d5ef143..65d549ff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=02-03

  Stats: 10 lines in 3 files changed: 2 ins; 6 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7688.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7688/head:pull/7688

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Mon Mar 14 13:24:43 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 14 Mar 2022 13:24:43 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <aGHdbwho5tW_Q2R6qGPywpUQKjYucFtIUIY_jVplW9w=.e61cda24-f306-4a71-b4d3-7be59f06b897@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
 <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
 <aGHdbwho5tW_Q2R6qGPywpUQKjYucFtIUIY_jVplW9w=.e61cda24-f306-4a71-b4d3-7be59f06b897@github.com>
Message-ID: <v9Zmi_qfrF4wwx-JkTABhPJMxmm0kGaJowXEAGd8JyQ=.974abe93-2524-4246-a2a4-930e03584632@github.com>

On Mon, 14 Mar 2022 10:04:13 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright years
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 155:
> 
>> 153:     boolean offerConnection(Http2Connection c) {
>> 154:         if (debug.on()) debug.log("offering to the connection pool: %s", c);
>> 155:         if (!c.isOpen() || c.finalStream()) {
> 
> Is this check for isOpen() not redundant given the same check added inside the synchronized block?

Possibly - but it allows to break out fast without having to enter the synchronized block.

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From ccleary at openjdk.java.net  Mon Mar 14 11:29:46 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 14 Mar 2022 11:29:46 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v2]
In-Reply-To: <Kkb44b46Xq1zd6lFgllDvKFVAW_gPbyJGSd7jMUNTZc=.3d600e2b-bbc9-4abd-8d1e-48d4f19b252b@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <p9reBBHP0p7l4xxPRfKFKl_At-RLmVS2eHRdevXZtH0=.9d03c1cf-b752-4286-bc48-5447a768b976@github.com>
 <Kkb44b46Xq1zd6lFgllDvKFVAW_gPbyJGSd7jMUNTZc=.3d600e2b-bbc9-4abd-8d1e-48d4f19b252b@github.com>
Message-ID: <JQioMvlk-kwf0cOwowGpDd9aItGnFFn9REUMNLIJrCA=.03e364e1-b6c7-474c-b346-a3ae6a1a7388@github.com>

On Mon, 7 Mar 2022 12:17:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8263031: Tidied up import statements
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 803:
> 
>> 801:             if (pcs != null) {
>> 802:                 if (frame instanceof ContinuationFrame cf) {
>> 803:                     handlePushContinuation(stream, cf);
> 
> IOException should probably be caught and transformed in protocol error here to?
> In case of protocol error when handling push promise (or their continuation) - should `pcs` be reset to null?
> Maybe it doesn't matter since we're closing the connection anyway.

In my opinion it would probably be safest to set pcs to null here yes.

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From michaelm at openjdk.java.net  Mon Mar 14 13:26:34 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 14 Mar 2022 13:26:34 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v5]
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <Z2Fgn-J5MfH47sNUtYpttWMUGeLS7NLAaHvUSuIBqKE=.c7c8f6d4-fd29-42d6-9dd5-eb527862873b@github.com>

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

Michael McMahon 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 17 additional commits since the last revision:

 - Merge branch 'master' into md5
 - update after third review round
 - removed swp file
 - update after second review round
 - update
 - update after first review round
 - fix whitespace
 - update property name. add documentation
 - fixed one more test
 - fixed up existing tests using digest auth
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/13dc4330...c55fdd94

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7688/files
  - new: https://git.openjdk.java.net/jdk/pull/7688/files/65d549ff..c55fdd94

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=03-04

  Stats: 15463 lines in 460 files changed: 9745 ins; 3242 del; 2476 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7688.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7688/head:pull/7688

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Mon Mar 14 13:26:35 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 14 Mar 2022 13:26:35 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v3]
In-Reply-To: <pwieeIUqDWAn8QjkAjnQwLQNoDdd4VLMLRq2bVIhymo=.481dac09-e6f7-4711-82c9-d1e30cac239e@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <pwieeIUqDWAn8QjkAjnQwLQNoDdd4VLMLRq2bVIhymo=.481dac09-e6f7-4711-82c9-d1e30cac239e@github.com>
Message-ID: <jVCX2_7VYTuDbcoWHEtaX5hLr-5O1UaPqiyOGWS4fX4=.7b23ebdd-2202-4648-9395-6e6b9ec43574@github.com>

On Fri, 11 Mar 2022 17:37:44 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update after second review round

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 102:

> 100:         propPrefix + "reEnabledAlgorithms";
> 101: 
> 102:     private static final Set<String> disabledAlgorithms = new HashSet<>();

It would be much better if this was an immutable set to make it MT-safe. You could set the value in the static block below using Set.copyOf().

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From duke at openjdk.java.net  Mon Mar 14 14:25:45 2022
From: duke at openjdk.java.net (zzambers)
Date: Mon, 14 Mar 2022 14:25:45 GMT
Subject: Integrated: 8282529: Fix API Note in javadoc for
 javax.net.ssl.SSLSocket
In-Reply-To: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
References: <Ay2qk_RoN56NoiNVLdGvOcZFXfq1RX4f2zrwrNL8ndY=.2ddda7cf-fcd2-49e9-928f-a13f1bc4d462@github.com>
Message-ID: <D9MpRM_v4H-5Ho6oGxcIULCoXziqisanaP3tf6kHHF8=.500eb8d2-c50d-48f9-8f22-70fb636946d3@github.com>

On Tue, 1 Mar 2022 17:09:57 GMT, zzambers <duke at openjdk.java.net> wrote:

> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208526
> [2] https://bugs.openjdk.java.net/browse/JDK-8216326

This pull request has now been integrated.

Changeset: 08573cc3
Author:    Zdenek Zambersky <zzambers at redhat.com>
Committer: Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/08573cc3b2370a697a7bd4ad0665ee20ae148d39
Stats:     13 lines in 1 file changed: 2 ins; 0 del; 11 mod

8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket

Reviewed-by: wetmore, xuelei

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

PR: https://git.openjdk.java.net/jdk/pull/7648

From rriggs at openjdk.java.net  Mon Mar 14 16:14:50 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 14 Mar 2022 16:14:50 GMT
Subject: RFR: 8282536: java.net.InetAddress should be a sealed class
In-Reply-To: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
References: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
Message-ID: <_oYz-pMXHncFUYFyLwmP7e9ApgduF-aqmJuBKzzlrR4=.77ad1708-9ca8-4029-8b26-a8030cad1f1b@github.com>

On Fri, 11 Mar 2022 16:47:46 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The following fix seals the `java.net.InetAddress` class and permits only two implementations - `java.net.Inet4Address` and `java.net.Inet6Address`. 
> 
> No issues have been detected by regression and JCK tests.
> 
> Links: [JBS](https://bugs.openjdk.java.net/browse/JDK-8282536) [CSR](https://bugs.openjdk.java.net/browse/JDK-8282880)

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7789

From achung at openjdk.java.net  Mon Mar 14 16:41:48 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Mar 2022 16:41:48 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
 <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>
Message-ID: <aFQYlAxHrt1xgVqg6IzAILy_arxPtISUJjV4XTInMIc=.98676675-43ef-44ef-bc29-935fb586e100@github.com>

On Thu, 10 Mar 2022 18:56:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   moved CurrencyNames changes to jdk.localedata
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305:
> 
>> 303:         {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"},
>> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
>> 305:         {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"},
> 
> I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added.

The translation was started before the updates to this file. This update can be done in the next msg drop.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From aefimov at openjdk.java.net  Mon Mar 14 16:45:24 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 14 Mar 2022 16:45:24 GMT
Subject: RFR: 8282536: java.net.InetAddress should be a sealed class [v2]
In-Reply-To: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
References: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
Message-ID: <Ky300bTbddbn2wZpMmE9JMouEDveFvk-k6xDaiZj6hQ=.409ef0fb-e50f-4192-b4c4-5c1616996c51@github.com>

> The following fix seals the `java.net.InetAddress` class and permits only two implementations - `java.net.Inet4Address` and `java.net.Inet6Address`. 
> 
> No issues have been detected by regression and JCK tests.
> 
> Links: [JBS](https://bugs.openjdk.java.net/browse/JDK-8282536) [CSR](https://bugs.openjdk.java.net/browse/JDK-8282880)

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup unnessecary class loader checks, remove readObjectNoData

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7789/files
  - new: https://git.openjdk.java.net/jdk/pull/7789/files/2096e6b8..f6901f09

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7789&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7789&range=00-01

  Stats: 23 lines in 2 files changed: 0 ins; 21 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7789.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7789/head:pull/7789

PR: https://git.openjdk.java.net/jdk/pull/7789

From aefimov at openjdk.java.net  Mon Mar 14 16:45:26 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 14 Mar 2022 16:45:26 GMT
Subject: RFR: 8282536: java.net.InetAddress should be a sealed class
In-Reply-To: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
References: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
Message-ID: <j7fVt6GBYbqfPgQ-cjyldhwZBvk91n6y5XnVpq-brLU=.04463fad-e40d-4443-b9b4-49ee83ffd4a5@github.com>

On Fri, 11 Mar 2022 16:47:46 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The following fix seals the `java.net.InetAddress` class and permits only two implementations - `java.net.Inet4Address` and `java.net.Inet6Address`. 
> 
> No issues have been detected by regression and JCK tests.
> 
> Links: [JBS](https://bugs.openjdk.java.net/browse/JDK-8282536) [CSR](https://bugs.openjdk.java.net/browse/JDK-8282880)

With only two sub-classes allowed the `InetAddress` code can be further cleaned-up by removing class loader checks. Pushed as f6901f098fe. Regression/JCK tests discovered no issues related to this change.

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

PR: https://git.openjdk.java.net/jdk/pull/7789

From kizune at openjdk.java.net  Mon Mar 14 17:41:55 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 14 Mar 2022 17:41:55 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <czftHGbEDrHytjmuT25dBWmgpN3gaiEPLmzDFtod0pA=.0c2274f6-25af-43fa-817f-0e41ede1c530@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

Marked as reviewed by kizune (Reviewer).

Clientlibs related stuff looks correct.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From achung at openjdk.java.net  Mon Mar 14 20:39:46 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Mar 2022 20:39:46 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed repeated lines from ROOT bundle in CurrencyNames

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/4735722d..d5c9b884

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=01-02

  Stats: 675 lines in 3 files changed: 0 ins; 675 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765

From weijun at openjdk.java.net  Mon Mar 14 21:45:54 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 14 Mar 2022 21:45:54 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v5]
In-Reply-To: <Z2Fgn-J5MfH47sNUtYpttWMUGeLS7NLAaHvUSuIBqKE=.c7c8f6d4-fd29-42d6-9dd5-eb527862873b@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <Z2Fgn-J5MfH47sNUtYpttWMUGeLS7NLAaHvUSuIBqKE=.c7c8f6d4-fd29-42d6-9dd5-eb527862873b@github.com>
Message-ID: <BCLcx9gfvmtXQ7JoDtKjuCTEFxQpIFAU1plS6iW0BAo=.5bf22644-6989-4d88-9960-8750900f9027@github.com>

On Mon, 14 Mar 2022 13:26:34 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon 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 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into md5
>  - update after third review round
>  - removed swp file
>  - update after second review round
>  - update
>  - update after first review round
>  - fix whitespace
>  - update property name. add documentation
>  - fixed one more test
>  - fixed up existing tests using digest auth
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4bef4cc9...c55fdd94

LGTM now. It will be even nicer if the known answer tests in RFC 7616 can be included.

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7688

From naoto at openjdk.java.net  Mon Mar 14 21:58:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 14 Mar 2022 21:58:45 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3]
In-Reply-To: <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>
Message-ID: <AePZQwkLsjSCRROANYizCTzIfiMBaWBOgZaVcnJtm5k=.132459fa-34c1-487f-b2c0-ce1d9e9e5f60@github.com>

On Mon, 14 Mar 2022 20:39:46 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed repeated lines from ROOT bundle in CurrencyNames

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct_ja.properties line 1:

> 1: #

The change to this file (moving ct.properties to ct_ja.properties) does look suspicious. Looks like this is not a translation file, but some kind of a configuration for `javac`. If so, it should not be translated (and translation configuration in the closed repository should exclude this file)

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From michaelm at openjdk.java.net  Tue Mar 15 10:12:40 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 15 Mar 2022 10:12:40 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
 <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
Message-ID: <6_l9fFKdEWG2jZrn3KnvozZFquRvXYo3cXGOnlretIg=.d4fc44cc-cbda-45f0-8524-8cb655e0a821@github.com>

On Thu, 10 Mar 2022 17:05:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find enclosed a patch that solves an intermittent issue detected by the CancelRequestTest.java
>> 
>> If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled after the Http2Connection has been created, and the handshake has proceeded, and the response headers to the upgrade have been received, but before the HTTP/2 connection is offered to the HTTP/2 connection pool, the underlying TCP connection might get closed at a time where it won't be noticed immediately, resulting in putting a "dead" HTTP/2 connection in the pool. The next request to the same server will then fail with "ClosedChannelException".
>> 
>> The fix is to check the state of the underlying TCP connection before offering the HTTP/2 connection to the pool, and when retrieving it from the pool, and disabling the "connectionAborter" (which is there to abort the connection in case of connect timeout, or cancellation before connect is done) before offering the connection to the pool as well.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

Marked as reviewed by michaelm (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From michaelm at openjdk.java.net  Tue Mar 15 10:12:40 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 15 Mar 2022 10:12:40 GMT
Subject: RFR: 8254786: java/net/httpclient/CancelRequestTest.java failing
 intermittently [v3]
In-Reply-To: <v9Zmi_qfrF4wwx-JkTABhPJMxmm0kGaJowXEAGd8JyQ=.974abe93-2524-4246-a2a4-930e03584632@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
 <wUgWEnroLIa8V8bFs8BnjiQtxmAgDKYfZmGriiQVJNo=.483f13c3-e404-465b-bdf4-cacc97da239d@github.com>
 <aGHdbwho5tW_Q2R6qGPywpUQKjYucFtIUIY_jVplW9w=.e61cda24-f306-4a71-b4d3-7be59f06b897@github.com>
 <v9Zmi_qfrF4wwx-JkTABhPJMxmm0kGaJowXEAGd8JyQ=.974abe93-2524-4246-a2a4-930e03584632@github.com>
Message-ID: <Mek9adROwJC_p2CEXCuNaQ4RauTYemFgSrNmI6JvB7U=.0130367f-5c51-480a-8926-736194749eef@github.com>

On Mon, 14 Mar 2022 13:21:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 155:
>> 
>>> 153:     boolean offerConnection(Http2Connection c) {
>>> 154:         if (debug.on()) debug.log("offering to the connection pool: %s", c);
>>> 155:         if (!c.isOpen() || c.finalStream()) {
>> 
>> Is this check for isOpen() not redundant given the same check added inside the synchronized block?
>
> Possibly - but it allows to break out fast without having to enter the synchronized block.

Okay, that's fine.

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From michaelm at openjdk.java.net  Tue Mar 15 10:27:48 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 15 Mar 2022 10:27:48 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v3]
In-Reply-To: <jVCX2_7VYTuDbcoWHEtaX5hLr-5O1UaPqiyOGWS4fX4=.7b23ebdd-2202-4648-9395-6e6b9ec43574@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <pwieeIUqDWAn8QjkAjnQwLQNoDdd4VLMLRq2bVIhymo=.481dac09-e6f7-4711-82c9-d1e30cac239e@github.com>
 <jVCX2_7VYTuDbcoWHEtaX5hLr-5O1UaPqiyOGWS4fX4=.7b23ebdd-2202-4648-9395-6e6b9ec43574@github.com>
Message-ID: <XpfQfEBXjrwGQ54kiOIkjvhCpjrOoczVgnR1qdkckbY=.7dab23f4-564c-46ed-9ec9-09ce100a116b@github.com>

On Fri, 11 Mar 2022 18:12:27 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 after second review round
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 102:
> 
>> 100:         propPrefix + "reEnabledAlgorithms";
>> 101: 
>> 102:     private static final Set<String> disabledAlgorithms = new HashSet<>();
> 
> It would be much better if this was an immutable set to make it MT-safe. You could set the value in the static block below using Set.copyOf().

The Set is private to the class and is not modified after the static initializer completes.  It's not clear to me how using Set.copyOf provides stronger MT-safe guarantees than this.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From ccleary at openjdk.java.net  Tue Mar 15 11:29:46 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 15 Mar 2022 11:29:46 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v2]
In-Reply-To: <4vKLmfxNMtLaj6xKZONU6v6WtQRjc1BXyYBkcMmrt8k=.79f648b2-8619-454d-9419-b70affadc955@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <p9reBBHP0p7l4xxPRfKFKl_At-RLmVS2eHRdevXZtH0=.9d03c1cf-b752-4286-bc48-5447a768b976@github.com>
 <Kkb44b46Xq1zd6lFgllDvKFVAW_gPbyJGSd7jMUNTZc=.3d600e2b-bbc9-4abd-8d1e-48d4f19b252b@github.com>
 <4vKLmfxNMtLaj6xKZONU6v6WtQRjc1BXyYBkcMmrt8k=.79f648b2-8619-454d-9419-b70affadc955@github.com>
Message-ID: <AmW3FVgqPRV4FIuJ9wGXWVzyt2frlvWKSmbZXh2HPPs=.df2eea23-b13c-432b-ba61-50bb38277bc1@github.com>

On Mon, 14 Mar 2022 11:19:36 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 176:
>> 
>>> 174:             ContinuationFrame cf = new ContinuationFrame(streamid, HeaderFrame.END_HEADERS, encodedHeaders);
>>> 175: 
>>> 176:             try {
>> 
>> It would be good to have a test-case that creates 2 continuation frames too.
>
> Good idea yes, to check that the repeat continuation still behaves as expected. Should hopefully be straight forward to create another test case.

On this issue, there is a case where a faulty server might send an indefinite number of Continuations (maybe the server never sets an END_HEADERS flag). Should a safe guard for the Push Promise with Continuation/s case be put in place to prevent the faulty scenario?

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From dfuchs at openjdk.java.net  Tue Mar 15 13:03:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 15 Mar 2022 13:03:44 GMT
Subject: Integrated: 8254786: java/net/httpclient/CancelRequestTest.java
 failing intermittently
In-Reply-To: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
References: <ZwVd04tU3u5S0Rf2PVXm7xfU8hMZQdffqnWekvvR7aE=.0fa92b5c-1deb-4e09-bba2-503bb18f0f78@github.com>
Message-ID: <RLqHhogv9gxXOl4iSPuR0S_Ma5Bl_TUX7BdXJ1Tx0JQ=.6a702f07-3720-4ead-920d-579ebace0b55@github.com>

On Thu, 10 Mar 2022 16:44:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find enclosed a patch that solves an intermittent issue detected by the CancelRequestTest.java
> 
> If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled after the Http2Connection has been created, and the handshake has proceeded, and the response headers to the upgrade have been received, but before the HTTP/2 connection is offered to the HTTP/2 connection pool, the underlying TCP connection might get closed at a time where it won't be noticed immediately, resulting in putting a "dead" HTTP/2 connection in the pool. The next request to the same server will then fail with "ClosedChannelException".
> 
> The fix is to check the state of the underlying TCP connection before offering the HTTP/2 connection to the pool, and when retrieving it from the pool, and disabling the "connectionAborter" (which is there to abort the connection in case of connect timeout, or cancellation before connect is done) before offering the connection to the pool as well.

This pull request has now been integrated.

Changeset: 710653ce
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/710653ce1856d13161ae1786d7c5f71997536e78
Stats:     62 lines in 4 files changed: 43 ins; 6 del; 13 mod

8254786: java/net/httpclient/CancelRequestTest.java failing intermittently

Reviewed-by: jpai, michaelm

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

PR: https://git.openjdk.java.net/jdk/pull/7776

From dfuchs at openjdk.java.net  Tue Mar 15 13:06:49 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 15 Mar 2022 13:06:49 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v3]
In-Reply-To: <XpfQfEBXjrwGQ54kiOIkjvhCpjrOoczVgnR1qdkckbY=.7dab23f4-564c-46ed-9ec9-09ce100a116b@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <pwieeIUqDWAn8QjkAjnQwLQNoDdd4VLMLRq2bVIhymo=.481dac09-e6f7-4711-82c9-d1e30cac239e@github.com>
 <jVCX2_7VYTuDbcoWHEtaX5hLr-5O1UaPqiyOGWS4fX4=.7b23ebdd-2202-4648-9395-6e6b9ec43574@github.com>
 <XpfQfEBXjrwGQ54kiOIkjvhCpjrOoczVgnR1qdkckbY=.7dab23f4-564c-46ed-9ec9-09ce100a116b@github.com>
Message-ID: <k9TgTyi9ftw6A5wkcTbi9-N9AZvzikeER8YiBZGsMbY=.eeebecf6-47b3-42fb-a950-c222fb581156@github.com>

On Tue, 15 Mar 2022 10:24:43 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 102:
>> 
>>> 100:         propPrefix + "reEnabledAlgorithms";
>>> 101: 
>>> 102:     private static final Set<String> disabledAlgorithms = new HashSet<>();
>> 
>> It would be much better if this was an immutable set to make it MT-safe. You could set the value in the static block below using Set.copyOf().
>
> The Set is private to the class and is not modified after the static initializer completes.  It's not clear to me how using Set.copyOf provides stronger MT-safe guarantees than this.

Better safe than sorry. An alternative could be to use ConcurrentHashMap.newKeySet(); But since it's supposed to be both immutable and MT-safe then Set.copyOf() would probably be a lighter and better choice.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Tue Mar 15 13:16:44 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 15 Mar 2022 13:16:44 GMT
Subject: RFR: 8282536: java.net.InetAddress should be a sealed class [v2]
In-Reply-To: <Ky300bTbddbn2wZpMmE9JMouEDveFvk-k6xDaiZj6hQ=.409ef0fb-e50f-4192-b4c4-5c1616996c51@github.com>
References: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
 <Ky300bTbddbn2wZpMmE9JMouEDveFvk-k6xDaiZj6hQ=.409ef0fb-e50f-4192-b4c4-5c1616996c51@github.com>
Message-ID: <6KDcvsO0y-N5ubUVjCrnAfkTkEAQVqu65qGO36QCKOY=.8e404d5e-bf9d-4485-9fa0-49a57e1bb6f5@github.com>

On Mon, 14 Mar 2022 16:45:24 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> The following fix seals the `java.net.InetAddress` class and permits only two implementations - `java.net.Inet4Address` and `java.net.Inet6Address`. 
>> 
>> No issues have been detected by regression and JCK tests.
>> 
>> Links: [JBS](https://bugs.openjdk.java.net/browse/JDK-8282536) [CSR](https://bugs.openjdk.java.net/browse/JDK-8282880)
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup unnessecary class loader checks, remove readObjectNoData

Marked as reviewed by michaelm (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7789

From dfuchs at openjdk.java.net  Tue Mar 15 14:33:46 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 15 Mar 2022 14:33:46 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v2]
In-Reply-To: <AmW3FVgqPRV4FIuJ9wGXWVzyt2frlvWKSmbZXh2HPPs=.df2eea23-b13c-432b-ba61-50bb38277bc1@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <p9reBBHP0p7l4xxPRfKFKl_At-RLmVS2eHRdevXZtH0=.9d03c1cf-b752-4286-bc48-5447a768b976@github.com>
 <Kkb44b46Xq1zd6lFgllDvKFVAW_gPbyJGSd7jMUNTZc=.3d600e2b-bbc9-4abd-8d1e-48d4f19b252b@github.com>
 <4vKLmfxNMtLaj6xKZONU6v6WtQRjc1BXyYBkcMmrt8k=.79f648b2-8619-454d-9419-b70affadc955@github.com>
 <AmW3FVgqPRV4FIuJ9wGXWVzyt2frlvWKSmbZXh2HPPs=.df2eea23-b13c-432b-ba61-50bb38277bc1@github.com>
Message-ID: <0_6Rt6-YTVLUflvS6nz0DnQiFcM50N8pTlgRaFLzwQM=.e9cd1d63-1d34-4baa-aa72-3b26cfc2f389@github.com>

On Tue, 15 Mar 2022 11:26:55 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Good idea yes, to check that the repeat continuation still behaves as expected. Should hopefully be straight forward to create another test case.
>
> On this issue, there is a case where a faulty server might send an indefinite number of Continuations (maybe the server never sets an END_HEADERS flag). Should a safe guard for the Push Promise with Continuation/s case be put in place to prevent the faulty scenario?

It would be impossible to detect, but if the server is faulty and "forget" to set the END_HEADERS flag, then we will detect that because the next frame we receive won't be the ContinuationFrame we expect.

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From ccleary at openjdk.java.net  Tue Mar 15 14:54:35 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 15 Mar 2022 14:54:35 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v3]
In-Reply-To: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
Message-ID: <KR-J0IIIeX3DcnAj0EeAkbS7yYqb5_eGkplzyi_yHRk=.fe2e0441-4fcc-49ef-a6a2-4c95d9e1a3e0@github.com>

> **Problem**
> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
> 
> 
> java.io.IOException: no statuscode in response
> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
> ...
> 
> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
> 
> **Fix**
> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
> 
> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
> 
> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.

Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:

 - 8263031: Cleanup of changes in Http2Connection
 - 8263031: Added test for multiple Continuation Frames

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7696/files
  - new: https://git.openjdk.java.net/jdk/pull/7696/files/664a1105..c14f599e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=01-02

  Stats: 117 lines in 2 files changed: 74 ins; 11 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7696.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7696/head:pull/7696

PR: https://git.openjdk.java.net/jdk/pull/7696

From ccleary at openjdk.java.net  Tue Mar 15 14:54:36 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 15 Mar 2022 14:54:36 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v2]
In-Reply-To: <Kkb44b46Xq1zd6lFgllDvKFVAW_gPbyJGSd7jMUNTZc=.3d600e2b-bbc9-4abd-8d1e-48d4f19b252b@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <p9reBBHP0p7l4xxPRfKFKl_At-RLmVS2eHRdevXZtH0=.9d03c1cf-b752-4286-bc48-5447a768b976@github.com>
 <Kkb44b46Xq1zd6lFgllDvKFVAW_gPbyJGSd7jMUNTZc=.3d600e2b-bbc9-4abd-8d1e-48d4f19b252b@github.com>
Message-ID: <nTSpjlRp2EGPToSOOivQh2wYagPD4MIFZLCNBiztdDE=.c0566e17-aa8e-42c7-978b-1384dcac71d3@github.com>

On Mon, 7 Mar 2022 12:31:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8263031: Tidied up import statements
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 855:
> 
>> 853: 
>> 854:     private record PushContinuationState(HeaderDecoder pushContDecoder, PushPromiseFrame pushContFrame) {}
>> 855:     private volatile PushContinuationState pcs;
> 
> I'd prefer to have a longer name than `pcs` - `pushContinuationState` would make it less mysterious at the place where it's used.  Also it could be good to move these declarations (linew 854 and 855) higher in the file, where other instance variables are declared.

Changed to pushContinuationState, its a long name but definitely clearer

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From dfuchs at openjdk.java.net  Tue Mar 15 15:29:46 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 15 Mar 2022 15:29:46 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v3]
In-Reply-To: <KR-J0IIIeX3DcnAj0EeAkbS7yYqb5_eGkplzyi_yHRk=.fe2e0441-4fcc-49ef-a6a2-4c95d9e1a3e0@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <KR-J0IIIeX3DcnAj0EeAkbS7yYqb5_eGkplzyi_yHRk=.fe2e0441-4fcc-49ef-a6a2-4c95d9e1a3e0@github.com>
Message-ID: <97nD-o7fblhFyqztDiJsky6gcnHVH9X0kIKg3BgD3p8=.9866351f-1d61-4a3b-b15a-d4bbfe139ce8@github.com>

On Tue, 15 Mar 2022 14:54:35 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Problem**
>> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
>> 
>> 
>> java.io.IOException: no statuscode in response
>> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
>> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
>> ...
>> 
>> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
>> 
>> **Fix**
>> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
>> 
>> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
>> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
>> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
>> 
>> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.
>
> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8263031: Cleanup of changes in Http2Connection
>  - 8263031: Added test for multiple Continuation Frames

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 814:

> 812:                     // TODO: Maybe say what kind of frame was received instead
> 813:                     pushContinuationState = null;
> 814:                     protocolError(ErrorFrame.PROTOCOL_ERROR, "Expected a Continuation frame but received " + frame);

In all other places in this method we have `return;` just after a call to `protocolError`, except in the two places where your changes added one. For consistency you should probably add this `return;` statement, even if it's not strictly needed. It would avoid having to have to analyze the whole structure of the nested `if - then - else` to figure out that it's actually not needed.

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 880:

> 878:     private <T> void handlePushContinuation(Stream<T> parent, ContinuationFrame cf)
> 879:             throws IOException {
> 880:         decodeHeaders(cf, pushContinuationState.pushContDecoder);

I suggest declaring a local variable here to avoid reading pushContinuationState more than once.
Something like:


var pcs = pushContinuationState;

then use `pcs` wherever needed in that method.

test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 75:

> 73:     static HttpHeaders testHeaders;
> 74:     static HttpHeadersBuilder testHeadersBuilder;
> 75:     static int continuationCount;

Since these three static variables are set by one thread and read by another - they should all be volatile.

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From ccleary at openjdk.java.net  Tue Mar 15 15:36:24 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 15 Mar 2022 15:36:24 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v4]
In-Reply-To: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
Message-ID: <AwrHSViKFq3XZ55X1jNgxDoQPvqjB5F780qzdj4ZVl4=.f35d3225-f165-4449-b679-3e37796be631@github.com>

> **Problem**
> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
> 
> 
> java.io.IOException: no statuscode in response
> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
> ...
> 
> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
> 
> **Fix**
> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
> 
> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
> 
> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.

Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:

  8263031: Correct ordering of imports

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7696/files
  - new: https://git.openjdk.java.net/jdk/pull/7696/files/c14f599e..c2ae1e56

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=02-03

  Stats: 55 lines in 1 file changed: 27 ins; 28 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7696.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7696/head:pull/7696

PR: https://git.openjdk.java.net/jdk/pull/7696

From ccleary at openjdk.java.net  Tue Mar 15 15:36:26 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 15 Mar 2022 15:36:26 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v2]
In-Reply-To: <Kkb44b46Xq1zd6lFgllDvKFVAW_gPbyJGSd7jMUNTZc=.3d600e2b-bbc9-4abd-8d1e-48d4f19b252b@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <p9reBBHP0p7l4xxPRfKFKl_At-RLmVS2eHRdevXZtH0=.9d03c1cf-b752-4286-bc48-5447a768b976@github.com>
 <Kkb44b46Xq1zd6lFgllDvKFVAW_gPbyJGSd7jMUNTZc=.3d600e2b-bbc9-4abd-8d1e-48d4f19b252b@github.com>
Message-ID: <nRbyIriKkRmGGRydcVDWaaK99X1pCst1p_PVGFatEUA=.fb6e4caf-38b5-4cc5-a06a-1d9e9744c828@github.com>

On Mon, 7 Mar 2022 12:08:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8263031: Tidied up import statements
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 82:
> 
>> 80: import java.util.function.Function;
>> 81: import java.util.function.Supplier;
>> 82: 
> 
> Could we keep the original alphabetical ordering and have the java.* imports come before the jdk.* imports?

Done, this was just an IDE hiccup

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From michaelm at openjdk.java.net  Tue Mar 15 16:00:41 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 15 Mar 2022 16:00:41 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v6]
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <yzhAltlEdcWT1uBAuYofNWBtTDGQSrlKW_aSarDv6Cs=.3c9cbff3-98e6-4932-830b-054047eb3915@github.com>

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  made disabledAlgorithms immutable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7688/files
  - new: https://git.openjdk.java.net/jdk/pull/7688/files/c55fdd94..66c320ce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=04-05

  Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7688.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7688/head:pull/7688

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Tue Mar 15 18:24:56 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 15 Mar 2022 18:24:56 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v6]
In-Reply-To: <yzhAltlEdcWT1uBAuYofNWBtTDGQSrlKW_aSarDv6Cs=.3c9cbff3-98e6-4932-830b-054047eb3915@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <yzhAltlEdcWT1uBAuYofNWBtTDGQSrlKW_aSarDv6Cs=.3c9cbff3-98e6-4932-830b-054047eb3915@github.com>
Message-ID: <32Prn2TP52VYlC1k2f1RmlDUltyuyceAo7f2jEOd8NY=.6ac1d55a-8e25-4970-90cd-e5c2582e0ece@github.com>

On Tue, 15 Mar 2022 16:00:41 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   made disabledAlgorithms immutable

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From weijun at openjdk.java.net  Tue Mar 15 19:54:39 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 15 Mar 2022 19:54:39 GMT
Subject: RFR: 8282293: Domain value for system property
 jdk.https.negotiate.cbt should be case-insensitive [v2]
In-Reply-To: <c0YBds7s64SxmD1IlEcR--WgO7TVcm6aY59D1w_iA28=.7d83b765-0f9e-4aa5-b2fb-f211f7a1413f@github.com>
References: <SVBWH2-_dt8F-32pwoUSapzjkjK8tprOiBYC16NG-6A=.ca826485-c8f2-4328-aebb-e4be64bde5fa@github.com>
 <c0YBds7s64SxmD1IlEcR--WgO7TVcm6aY59D1w_iA28=.7d83b765-0f9e-4aa5-b2fb-f211f7a1413f@github.com>
Message-ID: <WhCM1B3ggzQm4qbu9XRvubWAnaXcDUB6m9YKPe7DCC8=.8b667f29-c850-472f-957c-c48551b095bf@github.com>

On Thu, 10 Mar 2022 05:59:14 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Domain value for system property jdk.https.negotiate.cbt  is case-insensitive now. Included Test has been updated to address the change.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update HttpsCB.java

src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java line 338:

> 336:                     return true;
> 337:                 }
> 338:                 String afterWildCard = domain.substring(1);

`domain` could be an empty string if the property value is "domain:a,,b". I know it's invalid but at least let's try our best to avoid a runtime exception. In fact, why is this variable necessary? It looks like `regionMatches` allows you to compare ...er... regions.

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

PR: https://git.openjdk.java.net/jdk/pull/7759

From mullan at openjdk.java.net  Tue Mar 15 20:46:46 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 15 Mar 2022 20:46:46 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
 [v6]
In-Reply-To: <yzhAltlEdcWT1uBAuYofNWBtTDGQSrlKW_aSarDv6Cs=.3c9cbff3-98e6-4932-830b-054047eb3915@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <yzhAltlEdcWT1uBAuYofNWBtTDGQSrlKW_aSarDv6Cs=.3c9cbff3-98e6-4932-830b-054047eb3915@github.com>
Message-ID: <1cvGugndgRhPC2cXp2XFl3yEdAvxqlXOS-aQMplTkSk=.9d0e52b6-6575-4a20-bf0e-4f5c6b7db7d0@github.com>

On Tue, 15 Mar 2022 16:00:41 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   made disabledAlgorithms immutable

Suggest changing the bug title to reflect that SHA-1 is now also disabled by default, i.e. "Disable http DIGEST mechanisms with MD5 or SHA-1 by default".

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From aefimov at openjdk.java.net  Wed Mar 16 12:00:13 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 16 Mar 2022 12:00:13 GMT
Subject: RFR: 8282536: java.net.InetAddress should be a sealed class [v3]
In-Reply-To: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
References: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
Message-ID: <G2LMDodTMrPb78vXtsNHgp9xvcABHPiunXtPkLBkmaY=.e48781d7-7583-4cb9-a929-a8577f2399d8@github.com>

> The following fix seals the `java.net.InetAddress` class and permits only two implementations - `java.net.Inet4Address` and `java.net.Inet6Address`. 
> 
> No issues have been detected by regression and JCK tests.
> 
> Links: [JBS](https://bugs.openjdk.java.net/browse/JDK-8282536) [CSR](https://bugs.openjdk.java.net/browse/JDK-8282880)

Aleksei Efimov 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 four additional commits since the last revision:

 - Merge branch 'master' into JDK-8282536_Seal_InetAddress
 - Cleanup unnessecary class loader checks, remove readObjectNoData
 - Add qualified Serializable usage with import
 - 8282536: java.net.InetAddress should be a sealed class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7789/files
  - new: https://git.openjdk.java.net/jdk/pull/7789/files/f6901f09..44e6ab12

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7789&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7789&range=01-02

  Stats: 10743 lines in 405 files changed: 6113 ins; 2397 del; 2233 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7789.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7789/head:pull/7789

PR: https://git.openjdk.java.net/jdk/pull/7789

From aefimov at openjdk.java.net  Wed Mar 16 13:35:00 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 16 Mar 2022 13:35:00 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress
Message-ID: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>

Hi,

This cleanup change removes `InetAddressImplFactory` class from `InetAddress`. The list of changes:
- Remove `InetAddressImplFactory` from `InetAddress`
- Since `isIPv6Supported` native code is identical for Windows and Unix implementations it was moved to the libnet's `InetAddress.c`.
- `InetAddressImplFactory.c` Windows and Unix implementations were removed

Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change

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

Commit messages:
 - Merge branch 'master' into JDK-8282917_Remove_InetAddressImplFactory
 - 8282917: Remove InetAddressImplFactory from InetAddress

Changes: https://git.openjdk.java.net/jdk/pull/7842/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7842&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282917
  Stats: 125 lines in 4 files changed: 18 ins; 105 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7842.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7842/head:pull/7842

PR: https://git.openjdk.java.net/jdk/pull/7842

From jpai at openjdk.java.net  Wed Mar 16 13:52:39 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 16 Mar 2022 13:52:39 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress
In-Reply-To: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
Message-ID: <uCGD5a8WUlECZFJxxeAxSEmNYiO2B3UmvuSBtDeT2Bw=.27d2231d-b80a-4cce-84fb-be3c69eacf3b@github.com>

On Wed, 16 Mar 2022 13:26:36 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> Hi,
> 
> This cleanup change removes `InetAddressImplFactory` class from `InetAddress`. The list of changes:
> - Remove `InetAddressImplFactory` from `InetAddress`
> - Since `isIPv6Supported` native code is identical for Windows and Unix implementations it was moved to the libnet's `InetAddress.c`.
> - `InetAddressImplFactory.c` Windows and Unix implementations were removed
> 
> Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change

src/java.base/share/native/libnet/InetAddress.c line 88:

> 86:  * Class:     java_net_InetAddress
> 87:  * Method:    isIPv6Supported
> 88:  * Signature: ()I

Hello Aleksei, should this be `()Z` to represent the binary name of the boolean type https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.3.2-200

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

PR: https://git.openjdk.java.net/jdk/pull/7842

From jpai at openjdk.java.net  Wed Mar 16 13:59:45 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 16 Mar 2022 13:59:45 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress
In-Reply-To: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
Message-ID: <ipe8hreFDzw459O1dVmkiDkNn4EZgGVUxm_0kPYQguM=.cd570585-9530-42c9-b423-c48b8ccbbaea@github.com>

On Wed, 16 Mar 2022 13:26:36 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> Hi,
> 
> This cleanup change removes `InetAddressImplFactory` class from `InetAddress`. The list of changes:
> - Remove `InetAddressImplFactory` from `InetAddress`
> - Since `isIPv6Supported` native code is identical for Windows and Unix implementations it was moved to the libnet's `InetAddress.c`.
> - `InetAddressImplFactory.c` Windows and Unix implementations were removed
> 
> Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change

src/java.base/share/native/libnet/InetAddress.c line 96:

> 94:     } else {
> 95:         return JNI_FALSE;
> 96:     }

I don't have knowledge of C or JNI, but the `Java_java_net_InetAddress_isIPv4Available` currently does:


return ipv4_available();

So maybe a similar construct can be used here instead of if/else blocks? I'm guessing `ipv6_available()` will be returning values that are compatible with `JNI_TRUE/JNI_FALSE`.

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

PR: https://git.openjdk.java.net/jdk/pull/7842

From aefimov at openjdk.java.net  Wed Mar 16 14:29:25 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 16 Mar 2022 14:29:25 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress [v2]
In-Reply-To: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
Message-ID: <TvZbxcW_gySfe4CgXnJo_tBkj4QVMHdgOqMXCDjVEI8=.827ab5c5-0edc-4d76-bf6d-ee1f706448ff@github.com>

> Hi,
> 
> This cleanup change removes `InetAddressImplFactory` class from `InetAddress`. The list of changes:
> - Remove `InetAddressImplFactory` from `InetAddress`
> - Since `isIPv6Supported` native code is identical for Windows and Unix implementations it was moved to the libnet's `InetAddress.c`.
> - `InetAddressImplFactory.c` Windows and Unix implementations were removed
> 
> Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7842/files
  - new: https://git.openjdk.java.net/jdk/pull/7842/files/0af45a2d..49fdd576

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7842&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7842&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7842.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7842/head:pull/7842

PR: https://git.openjdk.java.net/jdk/pull/7842

From aefimov at openjdk.java.net  Wed Mar 16 14:29:28 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 16 Mar 2022 14:29:28 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress [v2]
In-Reply-To: <uCGD5a8WUlECZFJxxeAxSEmNYiO2B3UmvuSBtDeT2Bw=.27d2231d-b80a-4cce-84fb-be3c69eacf3b@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
 <uCGD5a8WUlECZFJxxeAxSEmNYiO2B3UmvuSBtDeT2Bw=.27d2231d-b80a-4cce-84fb-be3c69eacf3b@github.com>
Message-ID: <UorC7wYhmUCewMbW-1HuhuoF_tIyStIPXE9AT8y4hHM=.8d31c6e5-0b82-4e53-a6a8-76114440af5e@github.com>

On Wed, 16 Mar 2022 13:49:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/native/libnet/InetAddress.c line 88:
> 
>> 86:  * Class:     java_net_InetAddress
>> 87:  * Method:    isIPv6Supported
>> 88:  * Signature: ()I
> 
> Hello Aleksei, should this be `()Z` to represent the binary name of the boolean type https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.3.2-200

Hi Jaikiran,
Yes, you're right - it should be `()Z`. The impl copied from `src/java.base/unix/native/libnet/InetAddressImplFactory.c` had incorrect header. Fixed in 49fdd576cade2e97639f827f9db6d0f1e31101e2

> src/java.base/share/native/libnet/InetAddress.c line 96:
> 
>> 94:     } else {
>> 95:         return JNI_FALSE;
>> 96:     }
> 
> I don't have knowledge of C or JNI, but the `Java_java_net_InetAddress_isIPv4Available` currently does:
> 
> 
> return ipv4_available();
> 
> So maybe a similar construct can be used here instead of if/else blocks? I'm guessing `ipv6_available()` will be returning values that are compatible with `JNI_TRUE/JNI_FALSE`.

I agree that it could be simplified to match `Java_java_net_InetAddress_isIPv4Available`. Changed in 49fdd576cade2e97639f827f9db6d0f1e31101e2

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

PR: https://git.openjdk.java.net/jdk/pull/7842

From dfuchs at openjdk.java.net  Wed Mar 16 14:37:57 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 16 Mar 2022 14:37:57 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress [v2]
In-Reply-To: <UorC7wYhmUCewMbW-1HuhuoF_tIyStIPXE9AT8y4hHM=.8d31c6e5-0b82-4e53-a6a8-76114440af5e@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
 <uCGD5a8WUlECZFJxxeAxSEmNYiO2B3UmvuSBtDeT2Bw=.27d2231d-b80a-4cce-84fb-be3c69eacf3b@github.com>
 <UorC7wYhmUCewMbW-1HuhuoF_tIyStIPXE9AT8y4hHM=.8d31c6e5-0b82-4e53-a6a8-76114440af5e@github.com>
Message-ID: <mkeujCAArTCBbrbo16hAsWzCzh_miZnSioOysqDPxzQ=.d1a7ae9c-d2f1-46e0-94fe-dfb089ea6c26@github.com>

On Wed, 16 Mar 2022 14:25:44 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/java.base/share/native/libnet/InetAddress.c line 96:
>> 
>>> 94:     } else {
>>> 95:         return JNI_FALSE;
>>> 96:     }
>> 
>> I don't have knowledge of C or JNI, but the `Java_java_net_InetAddress_isIPv4Available` currently does:
>> 
>> 
>> return ipv4_available();
>> 
>> So maybe a similar construct can be used here instead of if/else blocks? I'm guessing `ipv6_available()` will be returning values that are compatible with `JNI_TRUE/JNI_FALSE`.
>
> I agree that it could be simplified to match `Java_java_net_InetAddress_isIPv4Available`. Changed in 49fdd576cade2e97639f827f9db6d0f1e31101e2

Thanks for noticing that Jaikiran!

Both `ipv4_available()` and `ipv6_available()` are defined to return `jint` so the implementation in `Java_java_net_InetAddress_isIPv6Supported` is arguably the more correct (provided that the method being called returns 0 when the corresponding IP version is not available).

The signature in the comment should be changed as you suggest though.

Possibly we should consider having both methods use the same construct...

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

PR: https://git.openjdk.java.net/jdk/pull/7842

From aefimov at openjdk.java.net  Wed Mar 16 17:51:17 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 16 Mar 2022 17:51:17 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress [v3]
In-Reply-To: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
Message-ID: <PAUe3ik9DYsPdoXUGFnn_q6FJURda41gPY4CdZJpzKw=.08c57a00-c453-4cdc-a0a9-e7125c378f06@github.com>

> Hi,
> 
> This cleanup change removes `InetAddressImplFactory` class from `InetAddress`. The list of changes:
> - Remove `InetAddressImplFactory` from `InetAddress`
> - Since `isIPv6Supported` native code is identical for Windows and Unix implementations it was moved to the libnet's `InetAddress.c`.
> - `InetAddressImplFactory.c` Windows and Unix implementations were removed
> 
> Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Update Java_java_net_InetAddress_isIPv4Available signature comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7842/files
  - new: https://git.openjdk.java.net/jdk/pull/7842/files/49fdd576..0b75bb45

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7842&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7842&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/7842

From aefimov at openjdk.java.net  Wed Mar 16 17:51:19 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 16 Mar 2022 17:51:19 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress [v3]
In-Reply-To: <mkeujCAArTCBbrbo16hAsWzCzh_miZnSioOysqDPxzQ=.d1a7ae9c-d2f1-46e0-94fe-dfb089ea6c26@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
 <uCGD5a8WUlECZFJxxeAxSEmNYiO2B3UmvuSBtDeT2Bw=.27d2231d-b80a-4cce-84fb-be3c69eacf3b@github.com>
 <UorC7wYhmUCewMbW-1HuhuoF_tIyStIPXE9AT8y4hHM=.8d31c6e5-0b82-4e53-a6a8-76114440af5e@github.com>
 <mkeujCAArTCBbrbo16hAsWzCzh_miZnSioOysqDPxzQ=.d1a7ae9c-d2f1-46e0-94fe-dfb089ea6c26@github.com>
Message-ID: <QZ5mqkaC-dmi2vDLwgVF8U8qN8_73FFiOW37wJWa_ZU=.2299ccc0-d1d5-4127-bf97-354e07183e75@github.com>

On Wed, 16 Mar 2022 14:34:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I agree that it could be simplified to match `Java_java_net_InetAddress_isIPv4Available`. Changed in 49fdd576cade2e97639f827f9db6d0f1e31101e2
>
> Thanks for noticing that Jaikiran!
> 
> Both `ipv4_available()` and `ipv6_available()` are defined to return `jint` so the implementation in `Java_java_net_InetAddress_isIPv6Supported` is arguably the more correct (provided that the method being called returns 0 when the corresponding IP version is not available).
> 
> The signature in the comment should be changed as you suggest though.
> 
> Possibly we should consider having both methods use the same construct...

Current version should be ok since variables returned by `ipv4_available()` and `ipv6_available()` can only be initialized to `JNI_FALSE` or `JNI_TRUE`:
- `Java_java_net_InetAddress_isIPv4Available`[InetAddress.c] returns result of `ipv4_available`[net_util.c]
- `ipv4_available`[net_util.c] returns `IPv4_available` variable value
- `IPv4_available` value is initalized with a result returned by `IPv4_supported()`[net_util_md.c]
- `IPv4_supported()`[net_util_md.c] can return `JNI_TRUE` or `JNI_FALSE` only (in both Unix and Windows implementations)
-  Same stands true for `ipv6_available()`: only `JNI_TRUE` or `JNI_FALSE` can be returned

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

PR: https://git.openjdk.java.net/jdk/pull/7842

From dfuchs at openjdk.java.net  Wed Mar 16 17:54:50 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 16 Mar 2022 17:54:50 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress [v3]
In-Reply-To: <PAUe3ik9DYsPdoXUGFnn_q6FJURda41gPY4CdZJpzKw=.08c57a00-c453-4cdc-a0a9-e7125c378f06@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
 <PAUe3ik9DYsPdoXUGFnn_q6FJURda41gPY4CdZJpzKw=.08c57a00-c453-4cdc-a0a9-e7125c378f06@github.com>
Message-ID: <q75yIuus9sOI2gsxAG-otDFqdqKD81G1Aenp8e95mjs=.17993ab2-d877-4d59-bb70-ffeeb3a3981f@github.com>

On Wed, 16 Mar 2022 17:51:17 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Hi,
>> 
>> This cleanup change removes `InetAddressImplFactory` class from `InetAddress`. The list of changes:
>> - Remove `InetAddressImplFactory` from `InetAddress`
>> - Since `isIPv6Supported` native code is identical for Windows and Unix implementations it was moved to the libnet's `InetAddress.c`.
>> - `InetAddressImplFactory.c` Windows and Unix implementations were removed
>> 
>> Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Java_java_net_InetAddress_isIPv4Available signature comment

Thanks for checking the result returned by ipv6_available() and ipv4_available(). Based on that information I believe what you have is good.

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7842

From achung at openjdk.java.net  Wed Mar 16 18:31:55 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 16 Mar 2022 18:31:55 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed incorrect translation of compiler configuration file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/d5c9b884..715a6ad7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=02-03

  Stats: 2310 lines in 3 files changed: 0 ins; 2310 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765

From naoto at openjdk.java.net  Wed Mar 16 21:40:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Mar 2022 21:40:44 GMT
Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4]
In-Reply-To: <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>
Message-ID: <e38JXXFphxIsB3GPU8tMLtEBR2d6nJ52y-1yWWYbA1I=.66a0c141-db54-4f02-8e75-28d9e562c002@github.com>

On Wed, 16 Mar 2022 18:31:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed incorrect translation of compiler configuration file

LGTM. Thanks for the change.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7765

From jpai at openjdk.java.net  Thu Mar 17 01:51:35 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 17 Mar 2022 01:51:35 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress [v3]
In-Reply-To: <PAUe3ik9DYsPdoXUGFnn_q6FJURda41gPY4CdZJpzKw=.08c57a00-c453-4cdc-a0a9-e7125c378f06@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
 <PAUe3ik9DYsPdoXUGFnn_q6FJURda41gPY4CdZJpzKw=.08c57a00-c453-4cdc-a0a9-e7125c378f06@github.com>
Message-ID: <oHv_APuy0Wa507mx6oMwlb3b822Cn_vnZMfANGg9LNk=.e2a31d65-fedd-4835-9e04-9a1161dbed09@github.com>

On Wed, 16 Mar 2022 17:51:17 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Hi,
>> 
>> This cleanup change removes `InetAddressImplFactory` class from `InetAddress`. The list of changes:
>> - Remove `InetAddressImplFactory` from `InetAddress`
>> - Since `isIPv6Supported` native code is identical for Windows and Unix implementations it was moved to the libnet's `InetAddress.c`.
>> - `InetAddressImplFactory.c` Windows and Unix implementations were removed
>> 
>> Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Java_java_net_InetAddress_isIPv4Available signature comment

Marked as reviewed by jpai (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/7842

From jpai at openjdk.java.net  Thu Mar 17 01:51:35 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 17 Mar 2022 01:51:35 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress [v3]
In-Reply-To: <QZ5mqkaC-dmi2vDLwgVF8U8qN8_73FFiOW37wJWa_ZU=.2299ccc0-d1d5-4127-bf97-354e07183e75@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
 <uCGD5a8WUlECZFJxxeAxSEmNYiO2B3UmvuSBtDeT2Bw=.27d2231d-b80a-4cce-84fb-be3c69eacf3b@github.com>
 <UorC7wYhmUCewMbW-1HuhuoF_tIyStIPXE9AT8y4hHM=.8d31c6e5-0b82-4e53-a6a8-76114440af5e@github.com>
 <mkeujCAArTCBbrbo16hAsWzCzh_miZnSioOysqDPxzQ=.d1a7ae9c-d2f1-46e0-94fe-dfb089ea6c26@github.com>
 <QZ5mqkaC-dmi2vDLwgVF8U8qN8_73FFiOW37wJWa_ZU=.2299ccc0-d1d5-4127-bf97-354e07183e75@github.com>
Message-ID: <lMny7zNBw-1H4psK0wFkxSLxAnkKKJEnEDenah_85Rk=.0b6ce2f6-d667-4616-998c-63ca9b4a8a08@github.com>

On Wed, 16 Mar 2022 17:47:15 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Thanks for noticing that Jaikiran!
>> 
>> Both `ipv4_available()` and `ipv6_available()` are defined to return `jint` so the implementation in `Java_java_net_InetAddress_isIPv6Supported` is arguably the more correct (provided that the method being called returns 0 when the corresponding IP version is not available).
>> 
>> The signature in the comment should be changed as you suggest though.
>> 
>> Possibly we should consider having both methods use the same construct...
>
> Current version should be ok since variables returned by `ipv4_available()` and `ipv6_available()` can only be initialized to `JNI_FALSE` or `JNI_TRUE`:
> - `Java_java_net_InetAddress_isIPv4Available`[InetAddress.c] returns result of `ipv4_available`[net_util.c]
> - `ipv4_available`[net_util.c] returns `IPv4_available` variable value
> - `IPv4_available` value is initalized with a result returned by `IPv4_supported()`[net_util_md.c]
> - `IPv4_supported()`[net_util_md.c] can return `JNI_TRUE` or `JNI_FALSE` only (in both Unix and Windows implementations)
> -  Same stands true for `ipv6_available()`: only `JNI_TRUE` or `JNI_FALSE` can be returned

Thank you Aleksei for those details and the changes.

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

PR: https://git.openjdk.java.net/jdk/pull/7842

From xuelei at openjdk.java.net  Fri Mar 18 18:11:33 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 18 Mar 2022 18:11:33 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v5]
In-Reply-To: <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>
Message-ID: <h6VBYo5pjZSM3tpZ_Pu7biEZb0OxEk0CCaa57w3JXeQ=.941cea06-d6c2-4bf2-ab95-db19dc21adc5@github.com>

On Tue, 8 Mar 2022 08:02:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>> 
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more test case udpate

ping ...

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From wetmore at openjdk.java.net  Fri Mar 18 21:03:41 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 18 Mar 2022 21:03:41 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v5]
In-Reply-To: <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>
Message-ID: <U9_psiHWY0VpAn1nCoUDrHB5R5ovUCd7fhc3ZVUTj58=.9f4b37cf-512a-4b05-82df-1de0a2726ba2@github.com>

On Tue, 8 Mar 2022 08:02:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>> 
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more test case udpate

test/jdk/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java line 487:

> 485:         if ((local != null) && (remote != null)) {
> 486:             // If both failed, return the curthread's exception.
> 487:             local.addSuppressed(remote);

Copyright 2016->2022.

test/jdk/javax/net/ssl/ALPN/SSLSocketAlpnTest.java line 483:

> 481:         if ((local != null) && (remote != null)) {
> 482:             // If both failed, return the curthread's exception.
> 483:             local.addSuppressed(remote);

Copyright 2016->2022.

test/jdk/javax/net/ssl/SSLException/CheckSSLHandshakeException.java line 2:

> 1: /*
> 2:  * Copyright (C) 2022 THL A29 Limited, a Tencent company. All rights reserved.

I am unsure about the copyrights on these files.  They are probably ok, but you should get approval by someone more familiar.

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From wetmore at openjdk.java.net  Fri Mar 18 21:15:35 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 18 Mar 2022 21:15:35 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v5]
In-Reply-To: <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>
Message-ID: <idhaBGAvM-FkRsne3m084CFcNORk8lOU2YdGO5Hv8gs=.ca9613b0-b910-4a57-9389-76ac97c00a22@github.com>

On Tue, 8 Mar 2022 08:02:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>> 
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more test case udpate

Please see latest comments and let's verify the copyright is correct, but otherwise looks good.

test/jdk/javax/net/ssl/SSLException/CheckSSLHandshakeException.java line 32:

> 30: import java.util.Objects;
> 31: 
> 32: public class CheckSSLHandshakeException {

My personal preference would have been to combine all of these into a single testfile to minimize clutter in the logs and directories, but no strong objection.

test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java line 349:

> 347:                 }
> 348:             }
> 349:         } finally {

Copyright update

test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java line 544:

> 542:         /*
> 543:          * Check various exception conditions.
> 544:          */

Copyright update

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7722

From iris at openjdk.java.net  Fri Mar 18 23:08:28 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 18 Mar 2022 23:08:28 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v5]
In-Reply-To: <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>
Message-ID: <V-BpUjJF9o0VnesOSr2f8M0qNnTjIrDp_57VT0dQ0YU=.07256eea-5e0f-447e-9b6a-def66ab9bedc@github.com>

On Tue, 8 Mar 2022 08:02:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
>> 
>> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more test case udpate

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From iris at openjdk.java.net  Fri Mar 18 23:08:28 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 18 Mar 2022 23:08:28 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v5]
In-Reply-To: <U9_psiHWY0VpAn1nCoUDrHB5R5ovUCd7fhc3ZVUTj58=.9f4b37cf-512a-4b05-82df-1de0a2726ba2@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>
 <U9_psiHWY0VpAn1nCoUDrHB5R5ovUCd7fhc3ZVUTj58=.9f4b37cf-512a-4b05-82df-1de0a2726ba2@github.com>
Message-ID: <fRuBAijRvLxIjy-YhtKC2GAjwQemV8QSeQAiWijlPrg=.eeeba7d3-c9a3-4386-960c-3561e7c6d77d@github.com>

On Fri, 18 Mar 2022 21:00:40 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more test case udpate
>
> test/jdk/javax/net/ssl/SSLException/CheckSSLHandshakeException.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (C) 2022 THL A29 Limited, a Tencent company. All rights reserved.
> 
> I am unsure about the third-party copyrights on these files.  They are probably ok, but you should get approval by someone more familiar.
> 
> Secondly, in the Oracle environment, we generally use a trailing , comma after the date.  e.g.
> 
> `Copyright (C) 2022, `

The location of the copyright is fine.  No need to enforce Oracle date formatting.

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From wetmore at openjdk.java.net  Fri Mar 18 23:12:26 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 18 Mar 2022 23:12:26 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v5]
In-Reply-To: <V-BpUjJF9o0VnesOSr2f8M0qNnTjIrDp_57VT0dQ0YU=.07256eea-5e0f-447e-9b6a-def66ab9bedc@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>
 <V-BpUjJF9o0VnesOSr2f8M0qNnTjIrDp_57VT0dQ0YU=.07256eea-5e0f-447e-9b6a-def66ab9bedc@github.com>
Message-ID: <TQBplKTkR5d1hq9GGlNeerZwbVdY2BHuSPqgx9gtpNM=.c950d9ea-9938-4fe5-8ed9-48c6509e9348@github.com>

On Fri, 18 Mar 2022 23:05:36 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more test case udpate
>
> Marked as reviewed by iris (Reviewer).

Thanks, @irisclark!

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From xuelei at openjdk.java.net  Sat Mar 19 04:23:24 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 19 Mar 2022 04:23:24 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v6]
In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID: <MLr68YiCwb3K_Y7HL5-1A4Af01mXnCpasoHDXEHp2NI=.dc2aa610-0762-4354-9692-6e962b2082b7@github.com>

> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
> 
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  update copyright years

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7722/files
  - new: https://git.openjdk.java.net/jdk/pull/7722/files/61cc7934..5d0fcf2e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=04-05

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7722/head:pull/7722

PR: https://git.openjdk.java.net/jdk/pull/7722

From xuelei at openjdk.java.net  Sat Mar 19 04:23:25 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 19 Mar 2022 04:23:25 GMT
Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions
 [v5]
In-Reply-To: <idhaBGAvM-FkRsne3m084CFcNORk8lOU2YdGO5Hv8gs=.ca9613b0-b910-4a57-9389-76ac97c00a22@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
 <I3pnx638UnvfG-wSwxwnZ-O-Lb3yE_HFTWCUwcCfalk=.4aad2105-c3df-4b6a-89d7-9c36f8099332@github.com>
 <idhaBGAvM-FkRsne3m084CFcNORk8lOU2YdGO5Hv8gs=.ca9613b0-b910-4a57-9389-76ac97c00a22@github.com>
Message-ID: <xTLqwtugOQ1eMrrLArsIKlufRkPcT_4BhFCXiZoISHY=.70aeb0af-e574-4c53-83b0-a199b18da5d2@github.com>

On Fri, 18 Mar 2022 21:08:56 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more test case udpate
>
> test/jdk/javax/net/ssl/SSLException/CheckSSLHandshakeException.java line 32:
> 
>> 30: import java.util.Objects;
>> 31: 
>> 32: public class CheckSSLHandshakeException {
> 
> My personal preference would have been to combine all of these into a single testfile to minimize clutter in the logs and directories, but no strong objection.

I understand. I would like to have them in separated test cases so that it is easier to monitor the regressions in the future.

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From xuelei at openjdk.java.net  Sun Mar 20 06:49:56 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sun, 20 Mar 2022 06:49:56 GMT
Subject: Integrated: 8282723: Add constructors taking a cause to JSSE
 exceptions
In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com>
Message-ID: <ND61nwp7U_8q0-Hj2NUOysPZV2G92SmYvSn9nVizsQA=.88eeab29-7b56-40fa-aec0-4abe64d0a0fa@github.com>

On Mon, 7 Mar 2022 07:52:29 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions.  The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly.
> 
> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724

This pull request has now been integrated.

Changeset: 4df67426
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4df67426ed02f18af0757897acb28b636a317a91
Stats:     396 lines in 30 files changed: 264 ins; 53 del; 79 mod

8282723: Add constructors taking a cause to JSSE exceptions

Reviewed-by: wetmore, iris

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

PR: https://git.openjdk.java.net/jdk/pull/7722

From turbanoff at gmail.com  Sun Mar 20 20:53:56 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Sun, 20 Mar 2022 23:53:56 +0300
Subject: Confusing startLock.wait()/finishLock.wait() calls in
 WindowsSelectorImpl
Message-ID: <CAF+DQ5epb+V-=g=QihjVS+GLtGR+fVbdH8V6u+tb4OzMWwOr4Q@mail.gmail.com>

Hello.
I found confusing calls to Object.wait() in 2 methods:
1. sun.nio.ch.WindowsSelectorImpl.StartLock#waitForStart
https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java#L252
2. sun.nio.ch.WindowsSelectorImpl.FinishLock#waitForHelperThreads
https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java#L304

Methods 'sun.nio.ch.WindowsSelectorImpl.FinishLock#waitForHelperThreads'
and 'sun.nio.ch.WindowsSelectorImpl.StartLock#waitForStart'
are synchronized. It means they are synchronized on 'this'.
But, somewhy, this methods calls to 'wait()' via reference fields in
outer class:

private synchronized boolean waitForStart(SelectThread thread) {
   ...
  startLock.wait();

private synchronized void waitForHelperThreads() {
   ...
  finishLock.wait();


It seems confusing to me. I would expect that method 'wait()' to be
called directly on 'this' too.
For StartLock it even allows to mark it as a 'static' nested class
(minus one redundant field).
Is it intentional to call 'wait()' like this?


Andrey Turbanov

From ssahoo at openjdk.java.net  Tue Mar 22 07:51:18 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Tue, 22 Mar 2022 07:51:18 GMT
Subject: RFR: 8282293: Domain value for system property
 jdk.https.negotiate.cbt should be case-insensitive [v3]
In-Reply-To: <SVBWH2-_dt8F-32pwoUSapzjkjK8tprOiBYC16NG-6A=.ca826485-c8f2-4328-aebb-e4be64bde5fa@github.com>
References: <SVBWH2-_dt8F-32pwoUSapzjkjK8tprOiBYC16NG-6A=.ca826485-c8f2-4328-aebb-e4be64bde5fa@github.com>
Message-ID: <4S_tt6hVXD0LVZa8xwliUZfDaa-Govv5gYAuYziv4W8=.8c540ac0-229f-416f-a389-4706aa962fee@github.com>

> Domain value for system property jdk.https.negotiate.cbt  is case-insensitive now. Included Test has been updated to address the change.

Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:

  Update AbstractDelegateHttpsURLConnection.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7759/files
  - new: https://git.openjdk.java.net/jdk/pull/7759/files/6d276479..9f8a2081

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/7759

From ccleary at openjdk.java.net  Tue Mar 22 10:31:25 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 22 Mar 2022 10:31:25 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v5]
In-Reply-To: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
Message-ID: <q487p7oCmpYkUH51FrBS5M_MBU_BQNd5dgGmU-3suDk=.3442f4a6-6d52-4334-9952-cd8f83cf272f@github.com>

> **Problem**
> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
> 
> 
> java.io.IOException: no statuscode in response
> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
> ...
> 
> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
> 
> **Fix**
> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
> 
> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
> 
> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.

Conor Cleary has updated the pull request incrementally with four additional commits since the last revision:

 - 8263031: Added return statements and pcs var
 - 8263031: Test cleanup, added third case
 - Revert "Test cleanup, added third case"
   
   This reverts commit 5c1c0f5fea801923bc3352bf88c701768d78b11d.
 - Test cleanup, added third case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7696/files
  - new: https://git.openjdk.java.net/jdk/pull/7696/files/c2ae1e56..c0543da9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=03-04

  Stats: 27 lines in 2 files changed: 18 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7696.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7696/head:pull/7696

PR: https://git.openjdk.java.net/jdk/pull/7696

From dfuchs at openjdk.java.net  Tue Mar 22 11:01:37 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 22 Mar 2022 11:01:37 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v5]
In-Reply-To: <q487p7oCmpYkUH51FrBS5M_MBU_BQNd5dgGmU-3suDk=.3442f4a6-6d52-4334-9952-cd8f83cf272f@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <q487p7oCmpYkUH51FrBS5M_MBU_BQNd5dgGmU-3suDk=.3442f4a6-6d52-4334-9952-cd8f83cf272f@github.com>
Message-ID: <uQSVhkrZ19NP4FOeI0ZGI67PBWNzBpCNfwv3C9ZQFtw=.532c985f-ddb0-445a-86db-be05853ca751@github.com>

On Tue, 22 Mar 2022 10:31:25 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Problem**
>> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
>> 
>> 
>> java.io.IOException: no statuscode in response
>> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
>> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
>> ...
>> 
>> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
>> 
>> **Fix**
>> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
>> 
>> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
>> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
>> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
>> 
>> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.
>
> Conor Cleary has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - 8263031: Added return statements and pcs var
>  - 8263031: Test cleanup, added third case
>  - Revert "Test cleanup, added third case"
>    
>    This reverts commit 5c1c0f5fea801923bc3352bf88c701768d78b11d.
>  - Test cleanup, added third case

Thanks for making these changes! Still a few comments...

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 28:

> 26: package jdk.internal.net.http;
> 27: 
> 28: import jdk.internal.net.http.HttpConnection.HttpPublisher;

Could this line be pushed down to where other `jdk.*` imports are made?

test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 158:

> 156:         CompletableFuture<HttpResponse<String>> cf =
> 157:                 client.sendAsync(hreq, HttpResponse.BodyHandlers.ofString(UTF_8), pph);
> 158:         cf.join();

I'd suggest checking that we received the expected response code + body too

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From ssahoo at openjdk.java.net  Tue Mar 22 13:26:35 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Tue, 22 Mar 2022 13:26:35 GMT
Subject: RFR: 8282293: Domain value for system property
 jdk.https.negotiate.cbt should be case-insensitive [v2]
In-Reply-To: <WhCM1B3ggzQm4qbu9XRvubWAnaXcDUB6m9YKPe7DCC8=.8b667f29-c850-472f-957c-c48551b095bf@github.com>
References: <SVBWH2-_dt8F-32pwoUSapzjkjK8tprOiBYC16NG-6A=.ca826485-c8f2-4328-aebb-e4be64bde5fa@github.com>
 <c0YBds7s64SxmD1IlEcR--WgO7TVcm6aY59D1w_iA28=.7d83b765-0f9e-4aa5-b2fb-f211f7a1413f@github.com>
 <WhCM1B3ggzQm4qbu9XRvubWAnaXcDUB6m9YKPe7DCC8=.8b667f29-c850-472f-957c-c48551b095bf@github.com>
Message-ID: <yhKM5XVc7jgeRtl7Zq7Qyp3HPdM-FgZHmPESqNxjryU=.bd4e7d23-dea2-4273-9b39-c4bd191d454d@github.com>

On Tue, 15 Mar 2022 19:46:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update HttpsCB.java
>
> src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java line 338:
> 
>> 336:                     return true;
>> 337:                 }
>> 338:                 String afterWildCard = domain.substring(1);
> 
> `domain` could be an empty string if the property value is "domain:a,,b". I know it's invalid but at least let's try our best to avoid a runtime exception. In fact, why is this variable necessary? It looks like `regionMatches` allows you to compare ...er... regions.

Done.

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

PR: https://git.openjdk.java.net/jdk/pull/7759

From dfuchs at openjdk.java.net  Tue Mar 22 14:51:37 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 22 Mar 2022 14:51:37 GMT
Subject: RFR: 8281223: Improve the API documentation of
 HttpRequest.Builder::build to state that the default implementation provided
 by the JDK returns immutable objects. [v2]
In-Reply-To: <bGt0PR-Re9fXZukk1Sx2qrwaZgNuOmQd55UpAPCPU5U=.080615f7-0035-4e55-8954-394f6b3156bd@github.com>
References: <Ehef3olnK9IeqOqGDJs13r722_hkP2mFdu16GcDzkGg=.38f05bca-53b1-4fa6-a9c1-8eb8cec47dbe@github.com>
 <bGt0PR-Re9fXZukk1Sx2qrwaZgNuOmQd55UpAPCPU5U=.080615f7-0035-4e55-8954-394f6b3156bd@github.com>
Message-ID: <4l09Ar9c3qz1dYAtEuh6wIdEJCeh6MPYIJAYiHSvF9w=.62198c3f-bb84-413d-9a1b-e8badb25ff72@github.com>

On Tue, 15 Feb 2022 15:33:01 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> As described in the title, this is a simple change to the `HttpRequest.Builder::build` method to highlight that an immutable and reusable instance of an `HttpRequest` is created when this method is invoked. This is done by adding an `@implSpec` Javadoc Tag (details on `@implSpec` given [here](https://openjdk.java.net/jeps/8068562)). 
>> 
>> The detail added under the `@implSpec` Tag is similar to that provided at the interface-level Javadoc for Builder.
>> 
>> Please also review the CSR for this change: https://bugs.openjdk.java.net/browse/JDK-8281833
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281223: Updated description, added missing code tag

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7479

From weijun at openjdk.java.net  Tue Mar 22 15:47:39 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 22 Mar 2022 15:47:39 GMT
Subject: RFR: 8282293: Domain value for system property
 jdk.https.negotiate.cbt should be case-insensitive [v3]
In-Reply-To: <4S_tt6hVXD0LVZa8xwliUZfDaa-Govv5gYAuYziv4W8=.8c540ac0-229f-416f-a389-4706aa962fee@github.com>
References: <SVBWH2-_dt8F-32pwoUSapzjkjK8tprOiBYC16NG-6A=.ca826485-c8f2-4328-aebb-e4be64bde5fa@github.com>
 <4S_tt6hVXD0LVZa8xwliUZfDaa-Govv5gYAuYziv4W8=.8c540ac0-229f-416f-a389-4706aa962fee@github.com>
Message-ID: <hcWx5KgrCSB9ZvclTIb256rVr2xujRFp__-h1xOF0AU=.c95f7e9f-66a3-4c19-b5f7-64a31595f854@github.com>

On Tue, 22 Mar 2022 07:51:18 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Domain value for system property jdk.https.negotiate.cbt  is case-insensitive now. Included Test has been updated to address the change.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update AbstractDelegateHttpsURLConnection.java

Marked as reviewed by weijun (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7759

From rhalade at openjdk.java.net  Tue Mar 22 16:32:35 2022
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Tue, 22 Mar 2022 16:32:35 GMT
Subject: RFR: 8282293: Domain value for system property
 jdk.https.negotiate.cbt should be case-insensitive [v3]
In-Reply-To: <4S_tt6hVXD0LVZa8xwliUZfDaa-Govv5gYAuYziv4W8=.8c540ac0-229f-416f-a389-4706aa962fee@github.com>
References: <SVBWH2-_dt8F-32pwoUSapzjkjK8tprOiBYC16NG-6A=.ca826485-c8f2-4328-aebb-e4be64bde5fa@github.com>
 <4S_tt6hVXD0LVZa8xwliUZfDaa-Govv5gYAuYziv4W8=.8c540ac0-229f-416f-a389-4706aa962fee@github.com>
Message-ID: <s_YlTwX7ekOPdf8uY2XUchTAeTImfggQnuzSDFqp7IM=.53a42387-5298-4d07-87cd-ca2e689c67e8@github.com>

On Tue, 22 Mar 2022 07:51:18 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Domain value for system property jdk.https.negotiate.cbt  is case-insensitive now. Included Test has been updated to address the change.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update AbstractDelegateHttpsURLConnection.java

Marked as reviewed by rhalade (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7759

From ssahoo at openjdk.java.net  Wed Mar 23 06:50:34 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Wed, 23 Mar 2022 06:50:34 GMT
Subject: Integrated: 8282293: Domain value for system property
 jdk.https.negotiate.cbt should be case-insensitive
In-Reply-To: <SVBWH2-_dt8F-32pwoUSapzjkjK8tprOiBYC16NG-6A=.ca826485-c8f2-4328-aebb-e4be64bde5fa@github.com>
References: <SVBWH2-_dt8F-32pwoUSapzjkjK8tprOiBYC16NG-6A=.ca826485-c8f2-4328-aebb-e4be64bde5fa@github.com>
Message-ID: <97oXmMX1Yy5SS5Pt4PHkOsWojq39kls1UYfZZfby0Xw=.46fa1099-4320-400b-92a9-23dad11d51a4@github.com>

On Wed, 9 Mar 2022 15:03:31 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> Domain value for system property jdk.https.negotiate.cbt  is case-insensitive now. Included Test has been updated to address the change.

This pull request has now been integrated.

Changeset: 86015e15
Author:    Sibabrata Sahoo <ssahoo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/86015e15a5105a779ee065cca64479c8d4fbc074
Stats:     11 lines in 2 files changed: 8 ins; 0 del; 3 mod

8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive

Reviewed-by: weijun, rhalade

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

PR: https://git.openjdk.java.net/jdk/pull/7759

From aefimov at openjdk.java.net  Wed Mar 23 15:01:38 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 23 Mar 2022 15:01:38 GMT
Subject: Integrated: 8282536: java.net.InetAddress should be a sealed class
In-Reply-To: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
References: <2yfymMUchcEE0fh4ptX4dmqM3KerK9uNA_N0tryOcaM=.c6f35564-5782-4a22-beca-fe2c76944fb5@github.com>
Message-ID: <28meVH_dJPvNEhOcObUeC-mO1PU4gCTzTWEgyswBRq8=.1383e31c-3e6c-4d6a-8a25-568c8b5b4818@github.com>

On Fri, 11 Mar 2022 16:47:46 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The following fix seals the `java.net.InetAddress` class and permits only two implementations - `java.net.Inet4Address` and `java.net.Inet6Address`. 
> 
> No issues have been detected by regression and JCK tests.
> 
> Links: [JBS](https://bugs.openjdk.java.net/browse/JDK-8282536) [CSR](https://bugs.openjdk.java.net/browse/JDK-8282880)

This pull request has now been integrated.

Changeset: 2b291d83
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2b291d837ebfd9d0a61f26541107c6a5f1d43773
Stats:     26 lines in 2 files changed: 1 ins; 21 del; 4 mod

8282536: java.net.InetAddress should be a sealed class

Reviewed-by: dfuchs, jpai, rriggs, michaelm

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

PR: https://git.openjdk.java.net/jdk/pull/7789

From aefimov at openjdk.java.net  Wed Mar 23 23:04:28 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 23 Mar 2022 23:04:28 GMT
Subject: RFR: 8282917: Remove InetAddressImplFactory from InetAddress [v4]
In-Reply-To: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
Message-ID: <rggKBmjn4Hgxx2zve-4nxH9eqqZzEFdCr98DB568JMc=.efbe8b18-c87e-4371-88a0-cf30c75d4ee2@github.com>

> Hi,
> 
> This cleanup change removes `InetAddressImplFactory` class from `InetAddress`. The list of changes:
> - Remove `InetAddressImplFactory` from `InetAddress`
> - Since `isIPv6Supported` native code is identical for Windows and Unix implementations it was moved to the libnet's `InetAddress.c`.
> - `InetAddressImplFactory.c` Windows and Unix implementations were removed
> 
> Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change

Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into JDK-8282917_Remove_InetAddressImplFactory
 - Update Java_java_net_InetAddress_isIPv4Available signature comment
 - Address review comments
 - Merge branch 'master' into JDK-8282917_Remove_InetAddressImplFactory
 - 8282917: Remove InetAddressImplFactory from InetAddress

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7842/files
  - new: https://git.openjdk.java.net/jdk/pull/7842/files/0b75bb45..77d0664f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7842&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7842&range=02-03

  Stats: 7722 lines in 1062 files changed: 3843 ins; 1584 del; 2295 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7842.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7842/head:pull/7842

PR: https://git.openjdk.java.net/jdk/pull/7842

From jpai at openjdk.java.net  Thu Mar 24 06:46:01 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 24 Mar 2022 06:46:01 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v14]
In-Reply-To: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
Message-ID: <UvoxSYrtBRkY0o3_4HOQAFyr0KYzV5UG59rgBgqhtHc=.70ddfd40-c17d-4ab1-9c52-b00ffcb2ab54@github.com>

> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
> 
> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.

Jaikiran Pai 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 28 additional commits since the last revision:

 - Merge latest from master branch
 - merge latest from master branch
 - Merge latest from master branch
 - Merge latest changes from master branch
 - fix javadoc to mention HttpClient instead of HTTPClient
 - minor - rename variable in test
 - Merge latest from master branch
 - Merge latest from master branch
 - Merge latest from master branch
 - copyright year
 - ... and 18 more: https://git.openjdk.java.net/jdk/compare/22357f95...4c1361b2

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6690/files
  - new: https://git.openjdk.java.net/jdk/pull/6690/files/e163f13c..4c1361b2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=12-13

  Stats: 56356 lines in 1782 files changed: 31522 ins; 18795 del; 6039 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6690.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6690/head:pull/6690

PR: https://git.openjdk.java.net/jdk/pull/6690

From dfuchs at openjdk.java.net  Thu Mar 24 10:02:15 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 24 Mar 2022 10:02:15 GMT
Subject: RFR: 8209137: Add ability to bind to specific local address to
 HTTP client [v14]
In-Reply-To: <UvoxSYrtBRkY0o3_4HOQAFyr0KYzV5UG59rgBgqhtHc=.70ddfd40-c17d-4ab1-9c52-b00ffcb2ab54@github.com>
References: <ObT4-qTt6YWF1-FEzPEW9t3syZ7Mu7H-6r30RbLEVRg=.8207a731-8b18-409e-a720-03948d178e21@github.com>
 <UvoxSYrtBRkY0o3_4HOQAFyr0KYzV5UG59rgBgqhtHc=.70ddfd40-c17d-4ab1-9c52-b00ffcb2ab54@github.com>
Message-ID: <VqnV7-XoIAga_17tN2-N4qtamSA5lYfRz4mbC997Fpw=.a0099cfc-8420-49b7-8f2e-6f250585404c@github.com>

On Thu, 24 Mar 2022 06:46:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change proposes to implement the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8209137.
>> 
>> The change introduces a new API to allow applications to build a `java.net.http.HTTPClient` configured with a specific local address that will be used while creating `Socket`(s) for connections.
>
> Jaikiran Pai 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 28 additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - merge latest from master branch
>  - Merge latest from master branch
>  - Merge latest changes from master branch
>  - fix javadoc to mention HttpClient instead of HTTPClient
>  - minor - rename variable in test
>  - Merge latest from master branch
>  - Merge latest from master branch
>  - Merge latest from master branch
>  - copyright year
>  - ... and 18 more: https://git.openjdk.java.net/jdk/compare/6962a853...4c1361b2

I haven't rereviewed the test since it has not been updated yet. 
It would be good to have a unit test for the default implementation of the new method in HttpClient.Builder, as well as a test for its concrete implementation in HttpClientBuilderImpl.

src/java.net.http/share/classes/java/net/http/HttpClient.java line 385:

> 383:          * @return this builder
> 384:          * @throws UnsupportedOperationException if this builder doesn't support
> 385:          *         configuring a local address

Maybe there should be an `@implNote` to say that the default implementation of the HttpClient only supports `InetSocketAddress` - and that the port should be 0?
Possibly also extend the `@throws UnsupportedOperationException` to cover the case where the given address is not supported?
Something like:


         * @throws UnsupportedOperationException if this builder doesn't support
         *         configuring a local address, or if the given local address is not one
         *         supported by the concrete {@code HttpClient} implementation.

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientBuilderImpl.java line 140:

> 138:         return this;
> 139:     }
> 140: 

Either this should check that localAddr is an `InetSocketAddress` and that port = 0, and throw an UnsupportedOperationException in that case, or the build() method should specify what exception is thrown and when, if the local address passed to the HttpClient implementation is not supported - because some exception will be thrown at some point... IMO it would be better to do the check early - although we would probably redo it in the HttpClientImpl (but there it wouldn't fail unless something bad happened).

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

PR: https://git.openjdk.java.net/jdk/pull/6690

From ccleary at openjdk.java.net  Thu Mar 24 12:41:26 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 24 Mar 2022 12:41:26 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v6]
In-Reply-To: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
Message-ID: <vfx_lbOQ8HnlFX2UptS_f5cN1-tXKIg-hqToEUqVcmg=.56659245-2dbb-4a99-84ca-a0b9eb00b232@github.com>

> **Problem**
> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
> 
> 
> java.io.IOException: no statuscode in response
> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
> ...
> 
> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
> 
> **Fix**
> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
> 
> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
> 
> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.

Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:

 - 8263031: further verification of push promise and response
 - 8263031: Removed duplicate import

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7696/files
  - new: https://git.openjdk.java.net/jdk/pull/7696/files/c0543da9..55e2d993

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=04-05

  Stats: 48 lines in 2 files changed: 15 ins; 16 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7696.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7696/head:pull/7696

PR: https://git.openjdk.java.net/jdk/pull/7696

From ccleary at openjdk.java.net  Thu Mar 24 12:41:28 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 24 Mar 2022 12:41:28 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v5]
In-Reply-To: <uQSVhkrZ19NP4FOeI0ZGI67PBWNzBpCNfwv3C9ZQFtw=.532c985f-ddb0-445a-86db-be05853ca751@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <q487p7oCmpYkUH51FrBS5M_MBU_BQNd5dgGmU-3suDk=.3442f4a6-6d52-4334-9952-cd8f83cf272f@github.com>
 <uQSVhkrZ19NP4FOeI0ZGI67PBWNzBpCNfwv3C9ZQFtw=.532c985f-ddb0-445a-86db-be05853ca751@github.com>
Message-ID: <TvBDDrYuQ86nwnYeKDz83pHoxNUHkPOXQ9vzygBlo18=.dea99e55-dcf9-421d-9e77-fbf53f6c9032@github.com>

On Tue, 22 Mar 2022 10:57:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - 8263031: Added return statements and pcs var
>>  - 8263031: Test cleanup, added third case
>>  - Revert "Test cleanup, added third case"
>>    
>>    This reverts commit 5c1c0f5fea801923bc3352bf88c701768d78b11d.
>>  - Test cleanup, added third case
>
> test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java line 158:
> 
>> 156:         CompletableFuture<HttpResponse<String>> cf =
>> 157:                 client.sendAsync(hreq, HttpResponse.BodyHandlers.ofString(UTF_8), pph);
>> 158:         cf.join();
> 
> I'd suggest checking that we received the expected response code + body too

Further changes made to check response codes and bodies of both the response and push promise.

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From ccleary at openjdk.java.net  Thu Mar 24 12:42:41 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 24 Mar 2022 12:42:41 GMT
Subject: RFR: 8281223: Improve the API documentation of
 HttpRequest.Builder::build to state that the default implementation provided
 by the JDK returns immutable objects. [v2]
In-Reply-To: <bGt0PR-Re9fXZukk1Sx2qrwaZgNuOmQd55UpAPCPU5U=.080615f7-0035-4e55-8954-394f6b3156bd@github.com>
References: <Ehef3olnK9IeqOqGDJs13r722_hkP2mFdu16GcDzkGg=.38f05bca-53b1-4fa6-a9c1-8eb8cec47dbe@github.com>
 <bGt0PR-Re9fXZukk1Sx2qrwaZgNuOmQd55UpAPCPU5U=.080615f7-0035-4e55-8954-394f6b3156bd@github.com>
Message-ID: <zME8yDcEWb4H7UEjaBT0U8dNlsCRRQnioeCgSp3-XtI=.5d168a43-fa6c-43be-a5e2-ccf21f643c4b@github.com>

On Tue, 15 Feb 2022 15:33:01 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> As described in the title, this is a simple change to the `HttpRequest.Builder::build` method to highlight that an immutable and reusable instance of an `HttpRequest` is created when this method is invoked. This is done by adding an `@implSpec` Javadoc Tag (details on `@implSpec` given [here](https://openjdk.java.net/jeps/8068562)). 
>> 
>> The detail added under the `@implSpec` Tag is similar to that provided at the interface-level Javadoc for Builder.
>> 
>> Please also review the CSR for this change: https://bugs.openjdk.java.net/browse/JDK-8281833
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281223: Updated description, added missing code tag

Awaiting CSR approval and additonal review, keeping this PR active by commenting

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

PR: https://git.openjdk.java.net/jdk/pull/7479

From aefimov at openjdk.java.net  Thu Mar 24 13:55:50 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 24 Mar 2022 13:55:50 GMT
Subject: Integrated: 8282917: Remove InetAddressImplFactory from InetAddress
In-Reply-To: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
References: <myCDmd8T169caqmO8AkSx3xyRrYl9aP9_TuVIdu5wxk=.c8681c2c-3961-4d24-bd39-d383a30bc7c1@github.com>
Message-ID: <Zo8bMkKT28yME3fjl2y7Tn87RC-0J0axu0VdPZ8L1Bc=.d183af0b-23e3-4129-bebb-dd74ffd6ec35@github.com>

On Wed, 16 Mar 2022 13:26:36 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> Hi,
> 
> This cleanup change removes `InetAddressImplFactory` class from `InetAddress`. The list of changes:
> - Remove `InetAddressImplFactory` from `InetAddress`
> - Since `isIPv6Supported` native code is identical for Windows and Unix implementations it was moved to the libnet's `InetAddress.c`.
> - `InetAddressImplFactory.c` Windows and Unix implementations were removed
> 
> Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change

This pull request has now been integrated.

Changeset: 929b6a35
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/929b6a3556ce6f6ffb1a5ae14b7f87d21598eb21
Stats:     122 lines in 4 files changed: 15 ins; 105 del; 2 mod

8282917: Remove InetAddressImplFactory from InetAddress

Reviewed-by: dfuchs, jpai

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

PR: https://git.openjdk.java.net/jdk/pull/7842

From dfuchs at openjdk.java.net  Thu Mar 24 19:09:51 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 24 Mar 2022 19:09:51 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v6]
In-Reply-To: <vfx_lbOQ8HnlFX2UptS_f5cN1-tXKIg-hqToEUqVcmg=.56659245-2dbb-4a99-84ca-a0b9eb00b232@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <vfx_lbOQ8HnlFX2UptS_f5cN1-tXKIg-hqToEUqVcmg=.56659245-2dbb-4a99-84ca-a0b9eb00b232@github.com>
Message-ID: <NjY2KPCHu7C7qrrKyL0YyjWbOywsUI9w9Gtyz0x95D8=.4b8be19e-980f-43d8-977a-1647c70cbe06@github.com>

On Thu, 24 Mar 2022 12:41:26 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Problem**
>> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
>> 
>> 
>> java.io.IOException: no statuscode in response
>> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
>> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
>> ...
>> 
>> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
>> 
>> **Fix**
>> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
>> 
>> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
>> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
>> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
>> 
>> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.
>
> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8263031: further verification of push promise and response
>  - 8263031: Removed duplicate import

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 807:

> 805:                     } catch (UncheckedIOException e) {
> 806:                         debug.log("Error handling Push Promise with Continuation: " + e.getMessage(), e);
> 807:                         protocolError(ResetFrame.PROTOCOL_ERROR, e.getMessage());

I believe it would more clear to use `ErrorFrame.PROTOCOL_ERROR` or `GoAwayFrame.PROTOCOL_ERRROR` here and in the other calls to protocolError below, since we're not resetting the stream here but closing the whole connection with a `GoAwayFrame`.

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From jpai at openjdk.java.net  Fri Mar 25 09:51:44 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 25 Mar 2022 09:51:44 GMT
Subject: RFR: 8281223: Improve the API documentation of
 HttpRequest.Builder::build to state that the default implementation provided
 by the JDK returns immutable objects. [v2]
In-Reply-To: <bGt0PR-Re9fXZukk1Sx2qrwaZgNuOmQd55UpAPCPU5U=.080615f7-0035-4e55-8954-394f6b3156bd@github.com>
References: <Ehef3olnK9IeqOqGDJs13r722_hkP2mFdu16GcDzkGg=.38f05bca-53b1-4fa6-a9c1-8eb8cec47dbe@github.com>
 <bGt0PR-Re9fXZukk1Sx2qrwaZgNuOmQd55UpAPCPU5U=.080615f7-0035-4e55-8954-394f6b3156bd@github.com>
Message-ID: <sdEvk8KHQZrSqgvraBhlsh8ZynyijleCcJtLx9z9SOY=.f273e67d-ca77-4aa4-a2cf-4ad1823652cc@github.com>

On Tue, 15 Feb 2022 15:33:01 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> As described in the title, this is a simple change to the `HttpRequest.Builder::build` method to highlight that an immutable and reusable instance of an `HttpRequest` is created when this method is invoked. This is done by adding an `@implSpec` Javadoc Tag (details on `@implSpec` given [here](https://openjdk.java.net/jeps/8068562)). 
>> 
>> The detail added under the `@implSpec` Tag is similar to that provided at the interface-level Javadoc for Builder.
>> 
>> Please also review the CSR for this change: https://bugs.openjdk.java.net/browse/JDK-8281833
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281223: Updated description, added missing code tag

Marked as reviewed by jpai (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/7479

From michaelm at openjdk.java.net  Fri Mar 25 14:50:57 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 25 Mar 2022 14:50:57 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by
 default [v7]
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <kiqxOz-Q24Rk1srvuR-xS7iGCnSIjraPr3Xl9BaGMGc=.a13ff8b6-dfd0-4f38-b411-63f68f34aa7e@github.com>

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

Michael McMahon 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 22 additional commits since the last revision:

 - latest update
 - Merge branch 'master' into md5
 - delete .swp file
 - incomplete test update
 - made disabledAlgorithms immutable
 - Merge branch 'master' into md5
 - update after third review round
 - removed swp file
 - update after second review round
 - update
 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/7047a23e...2ef5636d

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7688/files
  - new: https://git.openjdk.java.net/jdk/pull/7688/files/66c320ce..2ef5636d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=05-06

  Stats: 7185 lines in 421 files changed: 3921 ins; 1034 del; 2230 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7688.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7688/head:pull/7688

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Fri Mar 25 15:07:40 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 25 Mar 2022 15:07:40 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by
 default [v8]
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <GNH1CJANaxVzaiFqUq69-Fi7WJJvwqvjd5OGWxpqi8M=.929b6659-5471-463a-ac02-03be6c3234c6@github.com>

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  forgot update to DigestAuth test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7688/files
  - new: https://git.openjdk.java.net/jdk/pull/7688/files/2ef5636d..b2095e02

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=06-07

  Stats: 25 lines in 1 file changed: 14 ins; 11 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7688.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7688/head:pull/7688

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Fri Mar 25 15:13:49 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 25 Mar 2022 15:13:49 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by
 default [v8]
In-Reply-To: <GNH1CJANaxVzaiFqUq69-Fi7WJJvwqvjd5OGWxpqi8M=.929b6659-5471-463a-ac02-03be6c3234c6@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <GNH1CJANaxVzaiFqUq69-Fi7WJJvwqvjd5OGWxpqi8M=.929b6659-5471-463a-ac02-03be6c3234c6@github.com>
Message-ID: <dbigp91kjpVfGaxd8ODogBAwfeN6YIaA0SnJfOCMjr0=.af865e8b-5fa9-4a18-bc16-b3149da73753@github.com>

On Fri, 25 Mar 2022 15:07:40 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgot update to DigestAuth test

webrevs 06 & 07 have the latest changes, if anyone is just looking at the incremental changes

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From ccleary at openjdk.java.net  Fri Mar 25 15:54:48 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 25 Mar 2022 15:54:48 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v6]
In-Reply-To: <NjY2KPCHu7C7qrrKyL0YyjWbOywsUI9w9Gtyz0x95D8=.4b8be19e-980f-43d8-977a-1647c70cbe06@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <vfx_lbOQ8HnlFX2UptS_f5cN1-tXKIg-hqToEUqVcmg=.56659245-2dbb-4a99-84ca-a0b9eb00b232@github.com>
 <NjY2KPCHu7C7qrrKyL0YyjWbOywsUI9w9Gtyz0x95D8=.4b8be19e-980f-43d8-977a-1647c70cbe06@github.com>
Message-ID: <oYw9iUoNd7G9P2pbH99uAOxpKH40Y0-79rL60dhqa-s=.1779443b-6270-4ee6-9062-d788705355d3@github.com>

On Thu, 24 Mar 2022 18:21:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8263031: further verification of push promise and response
>>  - 8263031: Removed duplicate import
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 807:
> 
>> 805:                     } catch (UncheckedIOException e) {
>> 806:                         debug.log("Error handling Push Promise with Continuation: " + e.getMessage(), e);
>> 807:                         protocolError(ResetFrame.PROTOCOL_ERROR, e.getMessage());
> 
> I believe it would more clear to use `ErrorFrame.PROTOCOL_ERROR` or `GoAwayFrame.PROTOCOL_ERRROR` here and in the other calls to protocolError below, since we're not resetting the stream here but closing the whole connection with a `GoAwayFrame`.

Oh yes, good point. I think `ErrorFrame.PROTOCOL_ERROR` would be the most appropriate here. I'll amend the change accordingly.

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From ccleary at openjdk.java.net  Fri Mar 25 15:58:50 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 25 Mar 2022 15:58:50 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v6]
In-Reply-To: <oYw9iUoNd7G9P2pbH99uAOxpKH40Y0-79rL60dhqa-s=.1779443b-6270-4ee6-9062-d788705355d3@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <vfx_lbOQ8HnlFX2UptS_f5cN1-tXKIg-hqToEUqVcmg=.56659245-2dbb-4a99-84ca-a0b9eb00b232@github.com>
 <NjY2KPCHu7C7qrrKyL0YyjWbOywsUI9w9Gtyz0x95D8=.4b8be19e-980f-43d8-977a-1647c70cbe06@github.com>
 <oYw9iUoNd7G9P2pbH99uAOxpKH40Y0-79rL60dhqa-s=.1779443b-6270-4ee6-9062-d788705355d3@github.com>
Message-ID: <YaJSHSpOoUjd8C-1_BbglvGyARUUgaz6w7uWiBPUjuc=.42c74b67-645b-4781-bb82-e345bdda3359@github.com>

On Fri, 25 Mar 2022 15:51:44 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 807:
>> 
>>> 805:                     } catch (UncheckedIOException e) {
>>> 806:                         debug.log("Error handling Push Promise with Continuation: " + e.getMessage(), e);
>>> 807:                         protocolError(ResetFrame.PROTOCOL_ERROR, e.getMessage());
>> 
>> I believe it would more clear to use `ErrorFrame.PROTOCOL_ERROR` or `GoAwayFrame.PROTOCOL_ERRROR` here and in the other calls to protocolError below, since we're not resetting the stream here but closing the whole connection with a `GoAwayFrame`.
>
> Oh yes, good point. I think `ErrorFrame.PROTOCOL_ERROR` would be the most appropriate here. I'll amend the change accordingly.

However, I'll look into the specification further for the other cases and see if they need be changed as well. Though closing the whole connection with `GoAwayFrame` seems correct

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From dfuchs at openjdk.java.net  Fri Mar 25 17:26:51 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 25 Mar 2022 17:26:51 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by
 default [v8]
In-Reply-To: <GNH1CJANaxVzaiFqUq69-Fi7WJJvwqvjd5OGWxpqi8M=.929b6659-5471-463a-ac02-03be6c3234c6@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <GNH1CJANaxVzaiFqUq69-Fi7WJJvwqvjd5OGWxpqi8M=.929b6659-5471-463a-ac02-03be6c3234c6@github.com>
Message-ID: <F7krUcMnYpnGpczaJdWkW7MfRm8LrZjfnXG5h8yoEGs=.dc93c8a6-d32d-405f-81be-b2b28627ba04@github.com>

On Fri, 25 Mar 2022 15:07:40 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgot update to DigestAuth test

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 524:

> 522:         }
> 523: 
> 524:         boolean session = algorithm.endsWith ("-sess");

should that be `digest.endsWith("-sess");` ?

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From chegar at openjdk.java.net  Sat Mar 26 10:47:49 2022
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Sat, 26 Mar 2022 10:47:49 GMT
Subject: RFR: 8281223: Improve the API documentation of
 HttpRequest.Builder::build to state that the default implementation provided
 by the JDK returns immutable objects. [v2]
In-Reply-To: <bGt0PR-Re9fXZukk1Sx2qrwaZgNuOmQd55UpAPCPU5U=.080615f7-0035-4e55-8954-394f6b3156bd@github.com>
References: <Ehef3olnK9IeqOqGDJs13r722_hkP2mFdu16GcDzkGg=.38f05bca-53b1-4fa6-a9c1-8eb8cec47dbe@github.com>
 <bGt0PR-Re9fXZukk1Sx2qrwaZgNuOmQd55UpAPCPU5U=.080615f7-0035-4e55-8954-394f6b3156bd@github.com>
Message-ID: <ACR4un44PyOWtMzcxRHURh0V7cUlfZGmGNr1m1SxgYg=.0819eac6-d19c-45b8-a955-98c3550697ae@github.com>

On Tue, 15 Feb 2022 15:33:01 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> As described in the title, this is a simple change to the `HttpRequest.Builder::build` method to highlight that an immutable and reusable instance of an `HttpRequest` is created when this method is invoked. This is done by adding an `@implSpec` Javadoc Tag (details on `@implSpec` given [here](https://openjdk.java.net/jeps/8068562)). 
>> 
>> The detail added under the `@implSpec` Tag is similar to that provided at the interface-level Javadoc for Builder.
>> 
>> Please also review the CSR for this change: https://bugs.openjdk.java.net/browse/JDK-8281833
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281223: Updated description, added missing code tag

LGTM

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

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7479

From michaelm at openjdk.java.net  Mon Mar 28 08:25:52 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 28 Mar 2022 08:25:52 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by
 default [v8]
In-Reply-To: <F7krUcMnYpnGpczaJdWkW7MfRm8LrZjfnXG5h8yoEGs=.dc93c8a6-d32d-405f-81be-b2b28627ba04@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <GNH1CJANaxVzaiFqUq69-Fi7WJJvwqvjd5OGWxpqi8M=.929b6659-5471-463a-ac02-03be6c3234c6@github.com>
 <F7krUcMnYpnGpczaJdWkW7MfRm8LrZjfnXG5h8yoEGs=.dc93c8a6-d32d-405f-81be-b2b28627ba04@github.com>
Message-ID: <HUg17gGMIpfayIgEpJsHhZ4S_we6thh3tIF0jwx0vxk=.6f0e6c76-f890-4f37-9c0c-d405394bdac6@github.com>

On Fri, 25 Mar 2022 17:21:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   forgot update to DigestAuth test
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 524:
> 
>> 522:         }
>> 523: 
>> 524:         boolean session = algorithm.endsWith ("-sess");
> 
> should that be `digest.endsWith("-sess");` ?

No, the digest field refers to the actual message digest algorithm (as known to the security libraries). The algorithm field holds the algorithm name as it is defined in  RFC71616.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Mon Mar 28 09:32:49 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 28 Mar 2022 09:32:49 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by
 default [v8]
In-Reply-To: <HUg17gGMIpfayIgEpJsHhZ4S_we6thh3tIF0jwx0vxk=.6f0e6c76-f890-4f37-9c0c-d405394bdac6@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <GNH1CJANaxVzaiFqUq69-Fi7WJJvwqvjd5OGWxpqi8M=.929b6659-5471-463a-ac02-03be6c3234c6@github.com>
 <F7krUcMnYpnGpczaJdWkW7MfRm8LrZjfnXG5h8yoEGs=.dc93c8a6-d32d-405f-81be-b2b28627ba04@github.com>
 <HUg17gGMIpfayIgEpJsHhZ4S_we6thh3tIF0jwx0vxk=.6f0e6c76-f890-4f37-9c0c-d405394bdac6@github.com>
Message-ID: <V84ZvA0T8M0EIv98Wj5_qo9-3gBFduliNRv3cBKcmgE=.3a10d937-06a7-4e66-93d8-df8b70854aa8@github.com>

On Mon, 28 Mar 2022 08:22:26 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 524:
>> 
>>> 522:         }
>>> 523: 
>>> 524:         boolean session = algorithm.endsWith ("-sess");
>> 
>> should that be `digest.endsWith("-sess");` ?
>
> No, the digest field refers to the actual message digest algorithm (as known to the security libraries). The algorithm field holds the algorithm name as it is defined in  RFC7616.

I am confused here - because you converted `algorithm` to upper case, so it should never end with `-sess`?

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From ccleary at openjdk.java.net  Mon Mar 28 10:26:24 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 28 Mar 2022 10:26:24 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v7]
In-Reply-To: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
Message-ID: <JDufuSM7p_AfmkRI9gQGkoFG9HbkSlWAUOZwli3U268=.397a88fb-dc97-4e40-8181-bf5d15027546@github.com>

> **Problem**
> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
> 
> 
> java.io.IOException: no statuscode in response
> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
> ...
> 
> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
> 
> **Fix**
> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
> 
> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
> 
> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.

Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:

  8263031: changed to ErrorFrame.PROTOCOL_ERROR

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7696/files
  - new: https://git.openjdk.java.net/jdk/pull/7696/files/55e2d993..b6d34d8e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7696&range=05-06

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From ccleary at openjdk.java.net  Mon Mar 28 10:26:25 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 28 Mar 2022 10:26:25 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v6]
In-Reply-To: <YaJSHSpOoUjd8C-1_BbglvGyARUUgaz6w7uWiBPUjuc=.42c74b67-645b-4781-bb82-e345bdda3359@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <vfx_lbOQ8HnlFX2UptS_f5cN1-tXKIg-hqToEUqVcmg=.56659245-2dbb-4a99-84ca-a0b9eb00b232@github.com>
 <NjY2KPCHu7C7qrrKyL0YyjWbOywsUI9w9Gtyz0x95D8=.4b8be19e-980f-43d8-977a-1647c70cbe06@github.com>
 <oYw9iUoNd7G9P2pbH99uAOxpKH40Y0-79rL60dhqa-s=.1779443b-6270-4ee6-9062-d788705355d3@github.com>
 <YaJSHSpOoUjd8C-1_BbglvGyARUUgaz6w7uWiBPUjuc=.42c74b67-645b-4781-bb82-e345bdda3359@github.com>
Message-ID: <Z5sY9TbTGiWW5XpfpKnqeKtI4fZTnAuVfVqUMB552tQ=.f94420b3-a223-4028-b5b0-ef5af6ee7fb7@github.com>

On Fri, 25 Mar 2022 15:55:54 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Oh yes, good point. I think `ErrorFrame.PROTOCOL_ERROR` would be the most appropriate here. I'll amend the change accordingly.
>
> However, I'll look into the specification further for the other cases and see if they need be changed as well. Though closing the whole connection with `GoAwayFrame` seems correct

I changed three more occurences to `ErrorFrame.PROTOCOL_ERROR`, its easier to understand and lines up more clearly with specification

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From michaelm at openjdk.java.net  Mon Mar 28 10:33:48 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 28 Mar 2022 10:33:48 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by
 default [v8]
In-Reply-To: <V84ZvA0T8M0EIv98Wj5_qo9-3gBFduliNRv3cBKcmgE=.3a10d937-06a7-4e66-93d8-df8b70854aa8@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <GNH1CJANaxVzaiFqUq69-Fi7WJJvwqvjd5OGWxpqi8M=.929b6659-5471-463a-ac02-03be6c3234c6@github.com>
 <F7krUcMnYpnGpczaJdWkW7MfRm8LrZjfnXG5h8yoEGs=.dc93c8a6-d32d-405f-81be-b2b28627ba04@github.com>
 <HUg17gGMIpfayIgEpJsHhZ4S_we6thh3tIF0jwx0vxk=.6f0e6c76-f890-4f37-9c0c-d405394bdac6@github.com>
 <V84ZvA0T8M0EIv98Wj5_qo9-3gBFduliNRv3cBKcmgE=.3a10d937-06a7-4e66-93d8-df8b70854aa8@github.com>
Message-ID: <JcwFKXc43W5u_9YVW58gTcNOKCuLxysSAmEz0gg4y1g=.b7b4c291-3348-4bfd-9f40-537f5d2bbdef@github.com>

On Mon, 28 Mar 2022 09:29:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> No, the digest field refers to the actual message digest algorithm (as known to the security libraries). The algorithm field holds the algorithm name as it is defined in  RFC7616.
>
> I am confused here - because you converted `algorithm` to upper case, so it should never end with `-sess`?

Look at line 478: The `algorithm` field is reset here to be the upper case of the digest name plus the -sess suffix in lower case.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Mon Mar 28 11:28:45 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 28 Mar 2022 11:28:45 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by
 default [v8]
In-Reply-To: <GNH1CJANaxVzaiFqUq69-Fi7WJJvwqvjd5OGWxpqi8M=.929b6659-5471-463a-ac02-03be6c3234c6@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <GNH1CJANaxVzaiFqUq69-Fi7WJJvwqvjd5OGWxpqi8M=.929b6659-5471-463a-ac02-03be6c3234c6@github.com>
Message-ID: <-0Ismc3oqWRKcIXaRpNVQrke3R2hYmrQxtb-IhlQNpU=.3a2977d2-5458-4ff3-a4e4-aeba5c4013d0@github.com>

On Fri, 25 Mar 2022 15:07:40 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
>> 
>> - Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgot update to DigestAuth test

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Mon Mar 28 11:28:45 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 28 Mar 2022 11:28:45 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by
 default [v8]
In-Reply-To: <JcwFKXc43W5u_9YVW58gTcNOKCuLxysSAmEz0gg4y1g=.b7b4c291-3348-4bfd-9f40-537f5d2bbdef@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
 <GNH1CJANaxVzaiFqUq69-Fi7WJJvwqvjd5OGWxpqi8M=.929b6659-5471-463a-ac02-03be6c3234c6@github.com>
 <F7krUcMnYpnGpczaJdWkW7MfRm8LrZjfnXG5h8yoEGs=.dc93c8a6-d32d-405f-81be-b2b28627ba04@github.com>
 <HUg17gGMIpfayIgEpJsHhZ4S_we6thh3tIF0jwx0vxk=.6f0e6c76-f890-4f37-9c0c-d405394bdac6@github.com>
 <V84ZvA0T8M0EIv98Wj5_qo9-3gBFduliNRv3cBKcmgE=.3a10d937-06a7-4e66-93d8-df8b70854aa8@github.com>
 <JcwFKXc43W5u_9YVW58gTcNOKCuLxysSAmEz0gg4y1g=.b7b4c291-3348-4bfd-9f40-537f5d2bbdef@github.com>
Message-ID: <UTGFNsbeHdv6JvxKv2YPMHZYycza1wkGU7IWMsJeIqY=.b3769b91-abce-4b6d-b66e-52e51e5a77f0@github.com>

On Mon, 28 Mar 2022 10:30:56 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I am confused here - because you converted `algorithm` to upper case, so it should never end with `-sess`?
>
> Look at line 478: The `algorithm` field is reset here to be the upper case of the digest name plus the -sess suffix in lower case.

Doh! Somehow I'd read that as `digestName = digestName + "-sess"`.
All clear now.

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From dfuchs at openjdk.java.net  Mon Mar 28 11:32:38 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 28 Mar 2022 11:32:38 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v7]
In-Reply-To: <JDufuSM7p_AfmkRI9gQGkoFG9HbkSlWAUOZwli3U268=.397a88fb-dc97-4e40-8181-bf5d15027546@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <JDufuSM7p_AfmkRI9gQGkoFG9HbkSlWAUOZwli3U268=.397a88fb-dc97-4e40-8181-bf5d15027546@github.com>
Message-ID: <HpUaWrvAaSYoRAeVIAqjmW7_1Cc1XrJ48uMbwnb_4WM=.36e45371-4845-4f61-8a46-a8e1365321aa@github.com>

On Mon, 28 Mar 2022 10:26:24 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Problem**
>> When a Continuation Frame is received by the httpclient using HTTP/2 after a Push Promise frame (can happen if the amount of headers to be sent in a single Push Promise frame exceeds the maximum frame size, so a Continuation frame is required), the following exception occurs:
>> 
>> 
>> java.io.IOException: no statuscode in response
>> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565)
>> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
>> ...
>> 
>> This exception occurs because there is no existing flow in `jdk/internal/net/http/Http2Connection.java` which accounts for the case where a PushPromiseFrame is received with the END_HEADERS flag set to 0x0. When this occurs, the only acceptable frame/s (as multiple continuations are also acceptable) that can be received by the client on the same stream is a continuation frame.
>> 
>> **Fix**
>> To ensure correct behavior, the following changes were made to `jdk/internal/net/http/Http2Connection.java`.
>> 
>> - The existing method `handlePushPromise()` was modified so that if the END_HEADERS flag is _unset_ (flags equal to 0x0), then a record used to track the state of the Push Promise containing a shared `HeaderDecoder` and the received `PushPromiseFrame` is initialised.
>> - When the subsequent `ContinuationFrame` is received in `processFrame()`, the method `handlePushContinuation()` is called instead of the default flow resulting in `stream.incoming(frame)` being called (the source of the incorrect behaviour originally).
>> - In `handlePushContinuation()`, the shared decoder is used to decode the received `ContinuationFrame` headers and if the `END_HEADERS` flag is set (flags equal to 0x4), the `HttpHeaders` object for the Push Promise as a whole is constructed which serves to combine the headers from both the `PushPromiseFrame` and the `ContinuationFrame`.
>> 
>> A regression test was included which verifies that the exception is not thrown and that the headers arrive correctly.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263031: changed to ErrorFrame.PROTOCOL_ERROR

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From dfuchs at openjdk.java.net  Mon Mar 28 11:32:39 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 28 Mar 2022 11:32:39 GMT
Subject: RFR: 8263031: HttpClient throws Exception if it receives a Push
 Promise that is too large [v6]
In-Reply-To: <Z5sY9TbTGiWW5XpfpKnqeKtI4fZTnAuVfVqUMB552tQ=.f94420b3-a223-4028-b5b0-ef5af6ee7fb7@github.com>
References: <AL6lzjCreZXy9EFEyFwsL9MFRM7wvsFGIUOkMmkGQYs=.4429ecb0-460f-4e29-978f-dc649e3b49e0@github.com>
 <vfx_lbOQ8HnlFX2UptS_f5cN1-tXKIg-hqToEUqVcmg=.56659245-2dbb-4a99-84ca-a0b9eb00b232@github.com>
 <NjY2KPCHu7C7qrrKyL0YyjWbOywsUI9w9Gtyz0x95D8=.4b8be19e-980f-43d8-977a-1647c70cbe06@github.com>
 <oYw9iUoNd7G9P2pbH99uAOxpKH40Y0-79rL60dhqa-s=.1779443b-6270-4ee6-9062-d788705355d3@github.com>
 <YaJSHSpOoUjd8C-1_BbglvGyARUUgaz6w7uWiBPUjuc=.42c74b67-645b-4781-bb82-e345bdda3359@github.com>
 <Z5sY9TbTGiWW5XpfpKnqeKtI4fZTnAuVfVqUMB552tQ=.f94420b3-a223-4028-b5b0-ef5af6ee7fb7@github.com>
Message-ID: <V5aeZpHNaSEGU0nKkOk3P9Dc5PQH29VeupOeSc6Sa9c=.2c1e4fe9-2a8f-4b0f-8b71-7501ac2548c4@github.com>

On Mon, 28 Mar 2022 10:22:29 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> However, I'll look into the specification further for the other cases and see if they need be changed as well. Though closing the whole connection with `GoAwayFrame` seems correct
>
> I changed three more occurences to `ErrorFrame.PROTOCOL_ERROR`, its easier to understand and lines up more clearly with specification

Make sure to run tier1, tier2 before integrating. Drop me a note when you are ready I will sponsor the change.

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

PR: https://git.openjdk.java.net/jdk/pull/7696

From michaelm at openjdk.java.net  Mon Mar 28 13:56:53 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 28 Mar 2022 13:56:53 GMT
Subject: RFR: 8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by
 default [v9]
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <zW7jesWH_88WuBcsRXIYN8cvSOD_vdSo7HecxQeP5N4=.dc5b5363-5770-4764-9d6f-a91ce0902786@github.com>

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

Michael McMahon 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 25 additional commits since the last revision:

 - merge branch 'master' into md5
 - Merge branch 'master' into md5
 - forgot update to DigestAuth test
 - latest update
 - Merge branch 'master' into md5
 - delete .swp file
 - incomplete test update
 - made disabledAlgorithms immutable
 - Merge branch 'master' into md5
 - update after third review round
 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/a77604cd...946142f3

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7688/files
  - new: https://git.openjdk.java.net/jdk/pull/7688/files/b2095e02..946142f3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7688&range=07-08

  Stats: 92145 lines in 1153 files changed: 75778 ins; 14325 del; 2042 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7688.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7688/head:pull/7688

PR: https://git.openjdk.java.net/jdk/pull/7688

From michaelm at openjdk.java.net  Mon Mar 28 13:56:53 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 28 Mar 2022 13:56:53 GMT
Subject: Integrated: 8281561: Disable http DIGEST mechanism with MD5 and SHA-1
 by default
In-Reply-To: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
References: <4f-9thpt6TAoYqyU55Z8tWawSo5F6amVa0_SO5PhxUs=.9cc4f64a-7f8c-4319-b092-d26a5a4f9fc3@github.com>
Message-ID: <BxBNhHdDCpSd_fMuAadx-5lLspNihrdn9t0ha552w8s=.fd6d874d-c1e6-4905-95d3-c1cf73ff0b2e@github.com>

On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256.
> 
> - Michael

This pull request has now been integrated.

Changeset: 7f2a3ca2
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7f2a3ca289ae14bec1af24d0a51e98ba697ce9c1
Stats:     585 lines in 14 files changed: 490 ins; 14 del; 81 mod

8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by default

Reviewed-by: weijun, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/7688

From achung at openjdk.java.net  Mon Mar 28 18:35:54 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 18:35:54 GMT
Subject: Integrated: 8280400: JDK 19 L10n resource files update - msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <Gltjkc_Ybexl1S5THR_ItVyUAyld7nfA_h8fTuf8qqQ=.875739c6-22bf-4338-8e20-3e6e1b090140@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

This pull request has now been integrated.

Changeset: c0aecd15
Author:    Alisen Chung <achung at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0aecd15ae8d7abf37901f785fccaff2317c3b23
Stats:     11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod

8280400: JDK 19 L10n resource files update - msgdrop 10

Reviewed-by: naoto, kizune

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From achung at openjdk.java.net  Mon Mar 28 21:30:15 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 21:30:15 GMT
Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10
Message-ID: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>

This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

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

Commit messages:
 - Revert "8280400: JDK 19 L10n resource files update - msgdrop 10"

Changes: https://git.openjdk.java.net/jdk/pull/8005/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8005&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283806
  Stats: 11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8005.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8005/head:pull/8005

PR: https://git.openjdk.java.net/jdk/pull/8005

From kcr at openjdk.java.net  Mon Mar 28 21:30:16 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 28 Mar 2022 21:30:16 GMT
Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <FaqSreLXyYzhr0FYhkqcq8UW9Dn8RNNX0C7kb7-RGkA=.ba08bc41-383f-4e23-8103-7f0ef391df19@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

I confirm that this is an exact backout of [JDK-8280400](https://bugs.openjdk.java.net/browse/JDK-8280400).

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

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/8005

From aefimov at openjdk.java.net  Mon Mar 28 21:52:04 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 28 Mar 2022 21:52:04 GMT
Subject: RFR: 8283772: Make sun.net.dns.ResolverConfiguration sealed
Message-ID: <cHJY_6Rpe7wvLb0BhhHfDSkdMi19PSN-jlRVk10zUSA=.e2547af2-67d3-450b-a0b6-3c7febac0f3e@github.com>

The following fix seals `sun.net.dns.ResolverConfiguration` abstract class.
`sun.net.dns.ResolverConfigurationImpl` is the only permitted subclass which has two O/S specific implementations: for `Windows` and `Unix` architectures. Both of them are marked as `final`.

Testing: `jdk-tier1`, `jdk-tier2`, `jdk-tier3` and `java.naming` JCK tests show no failures with the change.

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

Commit messages:
 - 8283772: Make sun.net.dns.ResolverConfiguration sealed

Changes: https://git.openjdk.java.net/jdk/pull/8006/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8006&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283772
  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8006.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8006/head:pull/8006

PR: https://git.openjdk.java.net/jdk/pull/8006

From naoto at openjdk.java.net  Mon Mar 28 22:44:36 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 22:44:36 GMT
Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <jtwpNmcgdU1P5vo-z1GqeBzGlkydOcOsamki-j7cdAA=.d2087435-7f1a-4a78-b8c5-91d4577745e5@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8005

From achung at openjdk.java.net  Mon Mar 28 23:40:44 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 23:40:44 GMT
Subject: Integrated: 8283806: [BACKOUT] JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <zrorEpgQ5H2ZmwvH02RY-vMNitbxb4vcyk7W_pXhThw=.dd16b716-2dc8-42e6-b70e-7b58196a88de@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

This pull request has now been integrated.

Changeset: 634800a5
Author:    Alisen Chung <achung at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/634800a536e7f9d148a4caa2663a60a2c5fc4929
Stats:     11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod

8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10

Reviewed-by: kcr, naoto

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

PR: https://git.openjdk.java.net/jdk/pull/8005

From dfuchs at openjdk.java.net  Tue Mar 29 08:39:50 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 29 Mar 2022 08:39:50 GMT
Subject: RFR: 8283772: Make sun.net.dns.ResolverConfiguration sealed
In-Reply-To: <cHJY_6Rpe7wvLb0BhhHfDSkdMi19PSN-jlRVk10zUSA=.e2547af2-67d3-450b-a0b6-3c7febac0f3e@github.com>
References: <cHJY_6Rpe7wvLb0BhhHfDSkdMi19PSN-jlRVk10zUSA=.e2547af2-67d3-450b-a0b6-3c7febac0f3e@github.com>
Message-ID: <RvTa81srCcyXC522Iuu_dgFVeEBO3ikOrjZycPPzojM=.ec799b93-5448-4325-9317-6aed607a229b@github.com>

On Mon, 28 Mar 2022 21:44:36 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The following fix seals `sun.net.dns.ResolverConfiguration` abstract class.
> `sun.net.dns.ResolverConfigurationImpl` is the only permitted subclass which has two O/S specific implementations: for `Windows` and `Unix` architectures. Both of them are marked as `final`.
> 
> Testing: `jdk-tier1`, `jdk-tier2`, `jdk-tier3` and `java.naming` JCK tests show no failures with the change.

LGTM.

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

PR: https://git.openjdk.java.net/jdk/pull/8006

From jpai at openjdk.java.net  Tue Mar 29 08:59:43 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 29 Mar 2022 08:59:43 GMT
Subject: RFR: 8283772: Make sun.net.dns.ResolverConfiguration sealed
In-Reply-To: <cHJY_6Rpe7wvLb0BhhHfDSkdMi19PSN-jlRVk10zUSA=.e2547af2-67d3-450b-a0b6-3c7febac0f3e@github.com>
References: <cHJY_6Rpe7wvLb0BhhHfDSkdMi19PSN-jlRVk10zUSA=.e2547af2-67d3-450b-a0b6-3c7febac0f3e@github.com>
Message-ID: <htIA97nhkUoQsBUm7qW4rUgOm4Ik2H2OZf5MPzY_t-E=.259f0e92-713e-4df9-a4b8-c05325709fe3@github.com>

On Mon, 28 Mar 2022 21:44:36 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The following fix seals `sun.net.dns.ResolverConfiguration` abstract class.
> `sun.net.dns.ResolverConfigurationImpl` is the only permitted subclass which has two O/S specific implementations: for `Windows` and `Unix` architectures. Both of them are marked as `final`.
> 
> Testing: `jdk-tier1`, `jdk-tier2`, `jdk-tier3` and `java.naming` JCK tests show no failures with the change.

Change look fine to me.

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

Marked as reviewed by jpai (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8006

From dfuchs at openjdk.java.net  Tue Mar 29 11:28:42 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 29 Mar 2022 11:28:42 GMT
Subject: RFR: 8283772: Make sun.net.dns.ResolverConfiguration sealed
In-Reply-To: <cHJY_6Rpe7wvLb0BhhHfDSkdMi19PSN-jlRVk10zUSA=.e2547af2-67d3-450b-a0b6-3c7febac0f3e@github.com>
References: <cHJY_6Rpe7wvLb0BhhHfDSkdMi19PSN-jlRVk10zUSA=.e2547af2-67d3-450b-a0b6-3c7febac0f3e@github.com>
Message-ID: <tLYFunglw6Bl3WxXx4U2rf-BYrn92L3p4yhAFWIi0sc=.835b81ca-646d-46d5-b672-1caaa9956a25@github.com>

On Mon, 28 Mar 2022 21:44:36 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The following fix seals `sun.net.dns.ResolverConfiguration` abstract class.
> `sun.net.dns.ResolverConfigurationImpl` is the only permitted subclass which has two O/S specific implementations: for `Windows` and `Unix` architectures. Both of them are marked as `final`.
> 
> Testing: `jdk-tier1`, `jdk-tier2`, `jdk-tier3` and `java.naming` JCK tests show no failures with the change.

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8006

From ccleary at openjdk.java.net  Tue Mar 29 16:26:08 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 29 Mar 2022 16:26:08 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
Message-ID: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>

**Issue**
When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 

**Solution**
`Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.

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

Commit messages:
 - 8283544: HttpClient GET method adds Content-Length: 0 header

Changes: https://git.openjdk.java.net/jdk/pull/8017/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8017&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283544
  Stats: 168 lines in 2 files changed: 159 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8017/head:pull/8017

PR: https://git.openjdk.java.net/jdk/pull/8017

From aefimov at openjdk.java.net  Tue Mar 29 17:09:49 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 29 Mar 2022 17:09:49 GMT
Subject: Integrated: 8283772: Make sun.net.dns.ResolverConfiguration sealed
In-Reply-To: <cHJY_6Rpe7wvLb0BhhHfDSkdMi19PSN-jlRVk10zUSA=.e2547af2-67d3-450b-a0b6-3c7febac0f3e@github.com>
References: <cHJY_6Rpe7wvLb0BhhHfDSkdMi19PSN-jlRVk10zUSA=.e2547af2-67d3-450b-a0b6-3c7febac0f3e@github.com>
Message-ID: <cFoOVLLGbDeQEmYGMR2cqhtqPliblfk0z8vFBo1bPSs=.9532486d-7eb3-4b93-8659-4cbc3cfd8e9c@github.com>

On Mon, 28 Mar 2022 21:44:36 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The following fix seals `sun.net.dns.ResolverConfiguration` abstract class.
> `sun.net.dns.ResolverConfigurationImpl` is the only permitted subclass which has two O/S specific implementations: for `Windows` and `Unix` architectures. Both of them are marked as `final`.
> 
> Testing: `jdk-tier1`, `jdk-tier2`, `jdk-tier3` and `java.naming` JCK tests show no failures with the change.

This pull request has now been integrated.

Changeset: 95913067
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9591306760ffa0725977db8d3bb66758baeafbf6
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8283772: Make sun.net.dns.ResolverConfiguration sealed

Reviewed-by: jpai, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/8006

From dfuchs at openjdk.java.net  Tue Mar 29 17:12:50 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 29 Mar 2022 17:12:50 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
In-Reply-To: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
Message-ID: <InS4KWII-c0T5MJl5-qeMF2gL5vkpwzpKKJMBz4ybro=.e470ab2f-762f-4472-8857-584b6cfb5bd4@github.com>

On Tue, 29 Mar 2022 15:44:58 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> **Issue**
> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
> 
> **Solution**
> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.

I would not expect that throwing an AssertionError in the handler on the server side would make the client (and the test) fail (except maybe in timeout?). I'd suggest printing a message on System.err and sending a different error code (like 400 for instance) if expectations are not met, and have the client side checks that it receives 200.

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From djelinski at openjdk.java.net  Tue Mar 29 18:34:45 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 29 Mar 2022 18:34:45 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
In-Reply-To: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
Message-ID: <VCYEfLz1npDaOiT42j3QYVKYh8gwAsrKQGjL97gwSF4=.13ba8c8d-89f9-4c34-a2b0-ccded7a8fcdf@github.com>

On Tue, 29 Mar 2022 15:44:58 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> **Issue**
> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
> 
> **Solution**
> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.

Changes requested by djelinski (Committer).

src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java line 302:

> 300: 
> 301:         // GET with no body should not set the Content-Length header
> 302:         if (requestPublisher != null || !"GET".equals(request.method())) {

Can we remove the check for "GET"? This way we will let the users decide if they want to send content-length or not, regardless of the chosen request method.

src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java line 305:

> 303:             if (contentLength == 0) {
> 304:                 systemHeadersBuilder.setHeader("Content-Length", "0");
> 305:                 System.err.println("in 1");

did you forget to remove this?

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From dfuchs at openjdk.java.net  Tue Mar 29 19:46:41 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 29 Mar 2022 19:46:41 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
In-Reply-To: <VCYEfLz1npDaOiT42j3QYVKYh8gwAsrKQGjL97gwSF4=.13ba8c8d-89f9-4c34-a2b0-ccded7a8fcdf@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <VCYEfLz1npDaOiT42j3QYVKYh8gwAsrKQGjL97gwSF4=.13ba8c8d-89f9-4c34-a2b0-ccded7a8fcdf@github.com>
Message-ID: <peMfyfhzAiNEoqIVd6UcUSkMipXK6f1hMndteaZm2AU=.9284b800-3165-428b-94fa-4cdc77aa5369@github.com>

On Tue, 29 Mar 2022 18:31:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> **Issue**
>> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
>> 
>> **Solution**
>> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java line 302:
> 
>> 300: 
>> 301:         // GET with no body should not set the Content-Length header
>> 302:         if (requestPublisher != null || !"GET".equals(request.method())) {
> 
> Can we remove the check for "GET"? This way we will let the users decide if they want to send content-length or not, regardless of the chosen request method.

Practically that would mean not sending Content-Length: 0 by default for GET, DELETE, and HEAD. All other requests methods would have either a Content-Length or Transfer-Encoding. I suspect that HEAD should probably be handled the same way than GET. But should DELETE not have a body? I know that some servers will balk if DELETE has a body. But would they expect Content-Length: 0 not to be included? @Michael-Mc-Mahon what do you think?

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From achung at openjdk.java.net  Wed Mar 30 00:54:29 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 30 Mar 2022 00:54:29 GMT
Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop 10
Message-ID: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>

redo of 8280400

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

Commit messages:
 - 8280400: JDK 19 L10n resource files update - msgdrop 10

Changes: https://git.openjdk.java.net/jdk/pull/8026/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8026&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283805
  Stats: 11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8026/head:pull/8026

PR: https://git.openjdk.java.net/jdk/pull/8026

From ccleary at openjdk.java.net  Wed Mar 30 08:25:39 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 30 Mar 2022 08:25:39 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
In-Reply-To: <VCYEfLz1npDaOiT42j3QYVKYh8gwAsrKQGjL97gwSF4=.13ba8c8d-89f9-4c34-a2b0-ccded7a8fcdf@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <VCYEfLz1npDaOiT42j3QYVKYh8gwAsrKQGjL97gwSF4=.13ba8c8d-89f9-4c34-a2b0-ccded7a8fcdf@github.com>
Message-ID: <TkL3ITSqhPn0J36sxYWRyMuSC1C6dVCl0fMuT6XRGvc=.9853ca90-d962-4ee8-b339-e33870dbfb78@github.com>

On Tue, 29 Mar 2022 18:23:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> **Issue**
>> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
>> 
>> **Solution**
>> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java line 305:
> 
>> 303:             if (contentLength == 0) {
>> 304:                 systemHeadersBuilder.setHeader("Content-Length", "0");
>> 305:                 System.err.println("in 1");
> 
> did you forget to remove this?

I did indeed, silly mistake on my part!

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From ccleary at openjdk.java.net  Wed Mar 30 08:29:40 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 30 Mar 2022 08:29:40 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v2]
In-Reply-To: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
Message-ID: <e9J0WhYQSasoCBLM54xILt6e8kR_3k7-AYVCIb7qdrc=.86882264-bee6-40c1-b189-dcbc5fbb6ea0@github.com>

> **Issue**
> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
> 
> **Solution**
> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.

Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:

  8283544: Removed testing comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8017/files
  - new: https://git.openjdk.java.net/jdk/pull/8017/files/5c1e3a72..cb02c76d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8017&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8017&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From ccleary at openjdk.java.net  Wed Mar 30 10:32:53 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 30 Mar 2022 10:32:53 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v2]
In-Reply-To: <InS4KWII-c0T5MJl5-qeMF2gL5vkpwzpKKJMBz4ybro=.e470ab2f-762f-4472-8857-584b6cfb5bd4@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <InS4KWII-c0T5MJl5-qeMF2gL5vkpwzpKKJMBz4ybro=.e470ab2f-762f-4472-8857-584b6cfb5bd4@github.com>
Message-ID: <4qDEUsgLtqKLi4IzXZqNTeC_W7l3qLqfY5wHIOUy4Rk=.89c4d674-d98b-4e80-9c54-ff7a8d90c825@github.com>

On Tue, 29 Mar 2022 17:09:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I would not expect that throwing an AssertionError in the handler on the server side would make the client (and the test) fail (except maybe in timeout?). I'd suggest printing a message on System.err and sending a different error code (like 400 for instance) if expectations are not met, and have the client side checks that it receives 200.

@dfuch Yes you're correct. I've just verified there that when there is a failure in the test's current state it is the handleResponse() method that throws an IO Exception rather than an AssertionError from the test methods. I think as you suggest, handling the Test Errors by response codes sent from the server makes the most sense in this case.

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From ccleary at openjdk.java.net  Wed Mar 30 10:46:38 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 30 Mar 2022 10:46:38 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v2]
In-Reply-To: <e9J0WhYQSasoCBLM54xILt6e8kR_3k7-AYVCIb7qdrc=.86882264-bee6-40c1-b189-dcbc5fbb6ea0@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <e9J0WhYQSasoCBLM54xILt6e8kR_3k7-AYVCIb7qdrc=.86882264-bee6-40c1-b189-dcbc5fbb6ea0@github.com>
Message-ID: <Q0AKt20kBsHVqC1b2hvG40_odo4MZ5ITPVZHg5HzZBg=.860431c1-4757-4c5e-953f-9734ed46420e@github.com>

On Wed, 30 Mar 2022 08:29:40 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> **Issue**
>> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
>> 
>> **Solution**
>> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8283544: Removed testing comments

On another note, I do a small check to see if the value given in the Content-length header is correct and matches up with the actual length of the body. That check is probably outside of the scope of this test and probably unecessary so I was considering removing it unless there are any arguments for keeping it.

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

PR: https://git.openjdk.java.net/jdk/pull/8017

From kcr at openjdk.java.net  Wed Mar 30 11:35:38 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 30 Mar 2022 11:35:38 GMT
Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop
 10
In-Reply-To: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
References: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
Message-ID: <EnIpfAYY92S_YJGTVXtEYAlGCdqtzUcbzEmSV1_Zduo=.eb6608f2-1158-474a-80bb-118baf99af89@github.com>

On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung <achung at openjdk.org> wrote:

> redo of 8280400

Since this is identical to the original fix, I would expect the same Tier2 test failure as reported in [JDK-8283804](https://bugs.openjdk.java.net/browse/JDK-8283804).

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

PR: https://git.openjdk.java.net/jdk/pull/8026

From ccleary at openjdk.java.net  Wed Mar 30 14:33:20 2022
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 30 Mar 2022 14:33:20 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v3]
In-Reply-To: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
Message-ID: <7N5oqoebHq8kxr8hDLOAG6VKfg7gyz1Tx12FlNKXNs8=.0db5458a-4864-4877-8ba8-f104e452d768@github.com>

> **Issue**
> When using the `HttpClient.send()` to send a GET request created using the `HttpRequest.newBuilder()`, a `Content-length: 0` header is set. This behaviour causes issues with many services as a body related header is usually not expected to be included with a GET request. 
> 
> **Solution**
> `Http1Request.java` was modified so that when the request method is a GET, a `Content-length` header is not added to the request. However, if a developer chooses to include a body in a GET request (though it is generally considered bad practice), a `Content-length` header with the appropriate value will be added.

Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:

  8283544: Moved test assertions out of HttpHandlers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8017/files
  - new: https://git.openjdk.java.net/jdk/pull/8017/files/cb02c76d..132c1f31

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8017&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8017&range=01-02

  Stats: 33 lines in 1 file changed: 11 ins; 4 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8017/head:pull/8017

PR: https://git.openjdk.java.net/jdk/pull/8017

From naoto at openjdk.java.net  Wed Mar 30 15:48:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 30 Mar 2022 15:48:38 GMT
Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop
 10
In-Reply-To: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
References: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
Message-ID: <a41NNQJWMB7s3ZKC9Oc0wOR6djcVyJwClVqybrBHmto=.7cabbe09-19b7-414f-8843-c2490eab98ea@github.com>

On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung <achung at openjdk.org> wrote:

> redo of 8280400

I believe `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties` and `test/jdk/sun/text/resources/LocaleData` have to be adjusted according to the l10n changes.

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

PR: https://git.openjdk.java.net/jdk/pull/8026

From michaelm at openjdk.java.net  Wed Mar 30 19:31:35 2022
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 30 Mar 2022 19:31:35 GMT
Subject: RFR: 8283544: HttpClient GET method adds Content-Length: 0 header
 [v3]
In-Reply-To: <peMfyfhzAiNEoqIVd6UcUSkMipXK6f1hMndteaZm2AU=.9284b800-3165-428b-94fa-4cdc77aa5369@github.com>
References: <rn4xLKuM_D1k9gsWQG_lMIVH_NwN7QOfCbA0aLGNbkg=.f4e7d8de-7f60-4dbf-b180-de85953c475f@github.com>
 <VCYEfLz1npDaOiT42j3QYVKYh8gwAsrKQGjL97gwSF4=.13ba8c8d-89f9-4c34-a2b0-ccded7a8fcdf@github.com>
 <peMfyfhzAiNEoqIVd6UcUSkMipXK6f1hMndteaZm2AU=.9284b800-3165-428b-94fa-4cdc77aa5369@github.com>
Message-ID: <mGMrEQheAWilPosSAdlnyGNDD8_5Edfgm__Lp2pX3K4=.bf4b4ec8-b2c6-4d03-b700-0cb5b9adb5ae@github.com>

On Tue, 29 Mar 2022 19:43:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java line 302:
>> 
>>> 300: 
>>> 301:         // GET with no body should not set the Content-Length header
>>> 302:         if (requestPublisher != null || !"GET".equals(request.method())) {
>> 
>> Can we remove the check for "GET"? This way we will let the users decide if they want to send content-length or not, regardless of the chosen request method.
>
> Practically that would mean not sending Content-Length: 0 by default for GET, DELETE, and HEAD. All other requests methods would have either a Content-Length or Transfer-Encoding. I suspect that HEAD should probably be handled the same way than GET. But should DELETE not have a body? I know that some servers will balk if DELETE has a body. But would they expect Content-Length: 0 not to be included? @Michael-Mc-Mahon what do you think?

RFC 7230 section 3.3.2 says:
"A user agent SHOULD NOT send a
   Content-Length header field when the request message does not contain
   a payload body and the method semantics do not anticipate such a
   body."
I don't think the DELETE method anticipates a a request body. So, it shouldn't have a Content-Length header either IMO. Same for HEAD also.

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

PR: https://git.openjdk.java.net/jdk/pull/8017