From darcy at openjdk.java.net Tue Feb 1 06:10:15 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Feb 2022 06:10:15 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v13] In-Reply-To: <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com> Message-ID: On Fri, 28 Jan 2022 16:58:55 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > spec update from CSR Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From xuelei at openjdk.java.net Tue Feb 1 06:47:00 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 1 Feb 2022 06:47:00 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v8] In-Reply-To: References: Message-ID: > 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 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Allow null input and return values ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/dfcb7f7d..b5161f75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=06-07 Stats: 62 lines in 1 file changed: 13 ins; 16 del; 33 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 Tue Feb 1 06:47:00 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 1 Feb 2022 06:47:00 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: References: Message-ID: <1GU_LQE4xPb-k02FTR5Hh-gqBhZTydgJsZf-7SwqY9M=.f972b0ea-0e93-4908-b890-7d57c26929d1@github.com> On Mon, 31 Jan 2022 21:26:46 GMT, Sean Mullan wrote: >> As there is increasing number of SSL parameters, applications may just use the constructor with no argument, and use the set methods individually. > > Ok. You should specify what the default value of the signature schemes parameter is for this constructor as it does for the other parameters. Good catch. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Tue Feb 1 06:58:12 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 1 Feb 2022 06:58:12 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v7] In-Reply-To: References: Message-ID: <-hZDJJn4jgc8PaH6tf8Bw1oCWbF8UaoFg5oqehCOBXo=.a5dc5158-de3d-4af2-9f90-35c02cd61ff2@github.com> On Mon, 31 Jan 2022 21:55:18 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Rollback to use captialized S > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 727: > >> 725: * Note that the underlying provider may define the default signature >> 726: * schemes for each SSL/TLS/DTLS connection. Applications may also use >> 727: * System Property, "jdk.tls.client.SignatureSchemes" and/or > > Use the javadoc annotation @systemProperty when referring to the system properties. Look at other code for examples. Thanks! Updated. > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 734: > >> 732: * pre-populated objects. >> 733: * >> 734: * @return a non-null, possibly zero-length array of signature scheme > > The other methods that return arrays like `getCipherSuites` and `getProtocols` return `null` if none have been set. While one could argue whether returning `null` or an empty array is better, there is already a precedent in this API of returning `null`, and with this API programmers will have to check for two different ways of checking for parameters that are not set. I'm not really sure if the inconsistency is worth it. Yes, it is arguable. The spec is updated, I will update the implementation if we are on the same page for the specification part. > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 765: > >> 763: * System Property, "jdk.tls.client.SignatureSchemes" and/or >> 764: * "jdk.tls.server.SignatureSchemes", to customize the provider-specific >> 765: * default signature schemes. If the {@code signatureSchemes} array is > > In this sentence does `signatureSchemes` mean the "*.SignatureSchemes" property or the `signatureSchemes` parameter? I don't think I understand this sentence. I think you should explain when the system property overrides the parameter in this API, and/or vice-versa. I removed this section in the setSignatureSchemes() method, and add more details in the getSignatureSchemes(). > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 774: > >> 772: * is empty (zero-length), the provider-specific default signature >> 773: * schemes will be used for the SSL/TLS/DTLS connection. >> 774: * @throws IllegalArgumentException if signatureSchemes is null, or if > > The other methods that accept arrays like `setCipherSuites` and `setProtocols` accept `null` as a parameter. Like my previous comment, it seems more important to keep this behavior consistent in the API and allow `null` as an acceptable value, which is also useful for clearing the current value of the parameter. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From michaelm at openjdk.java.net Tue Feb 1 07:30:19 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 1 Feb 2022 07:30:19 GMT Subject: Integrated: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon wrote: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael This pull request has now been integrated. Changeset: de3113b9 Author: Michael McMahon URL: https://git.openjdk.java.net/jdk/commit/de3113b998550021bb502cd6f766036fb8351e7d Stats: 858 lines in 12 files changed: 696 ins; 146 del; 16 mod 8279842: HTTPS Channel Binding support for Java GSS/Kerberos Co-authored-by: Weijun Wang Reviewed-by: dfuchs, weijun, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From jpai at openjdk.java.net Wed Feb 2 05:44:03 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 2 Feb 2022 05:44:03 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v8] In-Reply-To: References: Message-ID: <9IgvmAG1uJeST5tnrHcn5NlSxymfllOTUzX3DhU0opg=.c05c8132-2a9c-4e9b-a38a-6dfc66ae4b1f@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 22 additional commits since the last revision: - Merge latest from master branch - Merge latest from master branch - Merge latest from master branch - copyright year - By default add SocketPermission for java.net.http module to allow binding to non-ephemeral ports if local bind address is configured for HTTPClient - Merge latest master branch - Merge latest from master branch - add a security manager test to verify proper permission checks happen when local address is configured on HTTPClient - Merge latest from master branch - add a note to the javadoc of the new API to explain that calling localAddress() is only for advanced usages - ... and 12 more: https://git.openjdk.java.net/jdk/compare/ecc6bd5d...0990e021 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6690/files - new: https://git.openjdk.java.net/jdk/pull/6690/files/5ecb4db4..0990e021 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=06-07 Stats: 6332 lines in 269 files changed: 3590 ins; 1573 del; 1169 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 jpai at openjdk.java.net Wed Feb 2 06:18:39 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 2 Feb 2022 06:18:39 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v9] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: minor - rename variable in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6690/files - new: https://git.openjdk.java.net/jdk/pull/6690/files/0990e021..c7e50bec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=07-08 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 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 jpai at openjdk.java.net Wed Feb 2 06:18:41 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 2 Feb 2022 06:18:41 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v9] In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 14:28:01 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> minor - rename variable in test > > Generally it would be good if the test did not make any assumption on the presence - or absence - of either IPv4 or IPv6 on the tested machine. > The IPSupport test library class has methods that allows a test to inquire whether IPv6 or IPv4 are available - I would recommend using them to figure out which test cases can be tested on the machine the test runs on. @dfuch Hello Daniel, on a slightly unrelated note I see there's a PR which tries to address too many HTTPClient instances resulting in odd failures on Windows https://github.com/openjdk/jdk/pull/7263. In this current PR of mine, I have a new test `HttpClientLocalAddrTest` which will end up creating (atmost) 20 HTTPClient instances. In my runs so far, I haven't seen any failures due to the number of instances, but I don't have a Windows setup to verify if these many clients can end up creating any issues on them. Unlike the change in that other PR which reduces the HTTPClient instance to just one, we won't be able to use that trick here since this whole test intentionally attempts to create multiple different instance of the HTTPClient. I hope this won't cause any issues on those Windows setups. ------------- PR: https://git.openjdk.java.net/jdk/pull/6690 From myano at openjdk.java.net Wed Feb 2 08:37:21 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 2 Feb 2022 08:37:21 GMT Subject: RFR: 8279329: Remove hardcoded IPv4 available policy on Windows Message-ID: I added socket connection check same as IPv6_supported(). Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4 uninstall`), and set property `-Djava.net.preferIPv4Stack=true`, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is always set to 1(IPv4), because IPv4_supported() always returns TRUE. After applied this fix, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is set to 2(IPv6). It looks fine that IPv4_supported() returns FALSE. Would you review this fix? ------------- Commit messages: - 8279329: Remove hardcoded IPv4 available policy on Windows Changes: https://git.openjdk.java.net/jdk/pull/7317/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7317&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279329 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7317.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7317/head:pull/7317 PR: https://git.openjdk.java.net/jdk/pull/7317 From dfuchs at openjdk.java.net Wed Feb 2 10:53:11 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Feb 2022 10:53:11 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v9] In-Reply-To: References: Message-ID: <6Gu0r4yrJiL47bEnzVKhuygrgAERCtLHLSmCa4Xr8Lw=.0f735454-164c-4d9b-8761-657ed0bf6dea@github.com> On Wed, 2 Feb 2022 06:18:39 GMT, Jaikiran Pai 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 incrementally with one additional commit since the last revision: > > minor - rename variable in test src/java.base/share/lib/security/default.policy line 25: > 23: permission java.net.SocketPermission "*","connect,resolve"; > 24: // required if the HTTPClient is configured to use a local bind address > 25: permission java.net.SocketPermission "localhost:*","listen,resolve"; Acked: I see that binding a `SocketChannel` will call `SecurityManager::checkListen`. I'd have to double check with `SocketPermission` to verify `"localhost:*"` covers all the cases (that is - that it is sufficient to bind on any local interface) src/java.net.http/share/classes/java/net/http/HttpClient.java line 376: > 374: * correct {@code localAddr} is passed. Failure to do so can result in > 375: * requests sent through the {@code HTTPClient} to fail. > 376: * `{@code HTTPClient}` should probably `{@code HttpClient}` since that's how the class is named. test/jdk/java/net/httpclient/HttpClientLocalAddrTest.java line 73: > 71: * -Djdk.internal.httpclient.debug=true > 72: * HttpClientLocalAddrTest > 73: * Thanks for running with SecurityManager too. ------------- PR: https://git.openjdk.java.net/jdk/pull/6690 From dfuchs at openjdk.java.net Wed Feb 2 11:09:06 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Feb 2022 11:09:06 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v9] In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 14:28:01 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> minor - rename variable in test > > Generally it would be good if the test did not make any assumption on the presence - or absence - of either IPv4 or IPv6 on the tested machine. > The IPSupport test library class has methods that allows a test to inquire whether IPv6 or IPv4 are available - I would recommend using them to figure out which test cases can be tested on the machine the test runs on. > @dfuch Hello Daniel, on a slightly unrelated note I see there's a PR which tries to address too many HTTPClient instances resulting in odd failures on Windows #7263. > > In this current PR of mine, I have a new test `HttpClientLocalAddrTest` which will end up creating (atmost) 20 HTTPClient instances. In my runs so far, I haven't seen any failures due to the number of instances, but I don't have a Windows setup to verify if these many clients can end up creating any issues on them. Unlike the change in that other PR which reduces the HTTPClient instance to just one, we won't be able to use that trick here since this whole test intentionally attempts to create multiple different instance of the HTTPClient. I hope this won't cause any issues on those Windows setups. Hi Jaikiran. First sorry for the delay in reviewing this change. Hopefully I'll be able to dedicate some more time to it in the coming weeks. WRT to your concerns with the number of HttpClient instances created by your test, I don't think this will be an issue (until proven false). Michael has a PR out (https://git.openjdk.java.net/jdk/pull/7302) that should solve the issue by using Unix Domain Socket in the pipe implementation of the selector. Even though that might also remove the need for my PR I'm still intending to proceed with it - as it should be safer to backport a test-only change to jdk 18 / jdk 17. Your test will be in the main line only - so it can benefit from Michael's PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/6690 From djelinski at openjdk.java.net Wed Feb 2 11:58:08 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 2 Feb 2022 11:58:08 GMT Subject: RFR: 8279329: Remove hardcoded IPv4 available policy on Windows In-Reply-To: References: Message-ID: <-x4uaE0s-QVKJx3m133Ed0llzsOSLNsEMOiKH7Nyb_g=.e20e7f9c-0834-4155-8447-eb6b55f574f2@github.com> On Wed, 2 Feb 2022 08:31:08 GMT, Masanori Yano wrote: > I added socket connection check same as IPv6_supported(). > Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4 uninstall`), and set property `-Djava.net.preferIPv4Stack=true`, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is always set to 1(IPv4), because IPv4_supported() always returns TRUE. After applied this fix, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is set to 2(IPv6). > It looks fine that IPv4_supported() returns FALSE. > Would you review this fix? Looks good to me. You still need approval from a proper reviewer though. ------------- Marked as reviewed by djelinski (Author). PR: https://git.openjdk.java.net/jdk/pull/7317 From alanb at openjdk.java.net Wed Feb 2 12:35:07 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Feb 2022 12:35:07 GMT Subject: RFR: 8279329: Remove hardcoded IPv4 available policy on Windows In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 08:31:08 GMT, Masanori Yano wrote: > I added socket connection check same as IPv6_supported(). > Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4 uninstall`), and set property `-Djava.net.preferIPv4Stack=true`, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is always set to 1(IPv4), because IPv4_supported() always returns TRUE. After applied this fix, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is set to 2(IPv6). > It looks fine that IPv4_supported() returns FALSE. > Would you review this fix? This looks okay although I assume just one part of the changes need to work in an IPv6-only environment. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7317 From dfuchs at openjdk.java.net Wed Feb 2 13:11:06 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Feb 2022 13:11:06 GMT Subject: RFR: 8279329: Remove hardcoded IPv4 available policy on Windows In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 08:31:08 GMT, Masanori Yano wrote: > I added socket connection check same as IPv6_supported(). > Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4 uninstall`), and set property `-Djava.net.preferIPv4Stack=true`, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is always set to 1(IPv4), because IPv4_supported() always returns TRUE. After applied this fix, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is set to 2(IPv6). > It looks fine that IPv4_supported() returns FALSE. > Would you review this fix? This looks reasonable. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7317 From aefimov at openjdk.java.net Wed Feb 2 13:20:04 2022 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Wed, 2 Feb 2022 13:20:04 GMT Subject: RFR: 8279329: Remove hardcoded IPv4 available policy on Windows In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 08:31:08 GMT, Masanori Yano wrote: > I added socket connection check same as IPv6_supported(). > Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4 uninstall`), and set property `-Djava.net.preferIPv4Stack=true`, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is always set to 1(IPv4), because IPv4_supported() always returns TRUE. After applied this fix, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is set to 2(IPv6). > It looks fine that IPv4_supported() returns FALSE. > Would you review this fix? The change looks good to me. ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/7317 From msheppar at openjdk.java.net Wed Feb 2 13:20:05 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Wed, 2 Feb 2022 13:20:05 GMT Subject: RFR: 8279329: Remove hardcoded IPv4 available policy on Windows In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 08:31:08 GMT, Masanori Yano wrote: > I added socket connection check same as IPv6_supported(). > Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4 uninstall`), and set property `-Djava.net.preferIPv4Stack=true`, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is always set to 1(IPv4), because IPv4_supported() always returns TRUE. After applied this fix, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is set to 2(IPv6). > It looks fine that IPv4_supported() returns FALSE. > Would you review this fix? I was working on this -- we have yet to fully analyse various failures from a Windows IPv6 only run, the build for which also has changes from https://bugs.openjdk.java.net/browse/JDK-8279566 and some changes from https://bugs.openjdk.java.net/browse/JDK-8275640 We should have access to the test environment again next week to execute additional test runs ------------- PR: https://git.openjdk.java.net/jdk/pull/7317 From mullan at openjdk.java.net Wed Feb 2 14:48:18 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 2 Feb 2022 14:48:18 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v8] In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 06:47:00 GMT, Xue-Lei Andrew Fan 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 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Allow null input and return values A few more comments on the API. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 706: > 704: * over the SSL/TLS/DTLS protocols. > 705: *

> 706: * Note that the standard list of signature scheme names may be found in s/may be found/are defined/ src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 710: > 708: * "{@docRoot}/../specs/security/standard-names.html#signature-schemes"> > 709: * Signature Schemes section of the Java Security Standard Algorithm > 710: * Names Specification. Providers may support signature schemes not found s/found/defined/ src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 711: > 709: * Signature Schemes section of the Java Security Standard Algorithm > 710: * Names Specification. Providers may support signature schemes not found > 711: * in this list or might not use the recommended name for a certain s/might/may/ src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 714: > 712: * signature scheme. > 713: *

> 714: * The returned array could be {@code null}, in which case the underlying s/could be/may be/ Suggest rewording as "If the returned array is {@code null}, then the underlying ..." src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 718: > 716: * SSL/TLS/DTLS connections. > 717: *

> 718: * The returned array could be empty (zero-length), in which case the Suggest rewording as "If the returned array is empty (zero-length), then the ..." src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 720: > 718: * The returned array could be empty (zero-length), in which case the > 719: * signature scheme negotiation mechanism is turned off for SSL/TLS/DTLS > 720: * protocols, and the connections may not be able estabilished if the s/estabilished/to be established/ src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 723: > 721: * negotiation mechanism is required by a certain SSL/TLS/DTLS protocol. > 722: *

> 723: * The returned array could be neither {@code null} nor empty (zero-length), Suggest rewording as "If the returned array is not {@code null} or empty (zero-length), then the signature schemes .." src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 730: > 728: * For non-null returns, this method will return a new array each time it > 729: * is invoked. Providers should ignore unknown signature scheme names > 730: * while establishing the SSL/TLS/DTLS connections. I think this condition should be part of the API specification, and not the implementation specification. This needs to be a required part of the API, otherwise applications cannot safely rely on other implementations of this class to return copies. I suggest moving it to the `@returns` clause. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 736: > 734: * schemes for each SSL/TLS/DTLS connection. Applications may also use > 735: * System Property, {@systemProperty jdk.tls.client.SignatureSchemes} > 736: * and/or {@systemProperty jdk.tls.server.SignatureSchemes}, to customize Suggest rewording as "the {@systemProperty jdk.tls.client.SignatureSchemes} and/or {@systemProperty jdk.tls.server.SignatureSchemes} system properties to customize ..." src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 742: > 740: * objects, or {@code null} for pre-populated objects. > 741: * > 742: * @return {@code null} or an array of signature scheme {@code String}s. Suggest rephrasing as "an array of signature scheme {@code Strings} or {@null} if none have been set." src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 757: > 755: * can be used over the SSL/TLS/DTLS protocols. > 756: *

> 757: * Note that the standard list of signature scheme names may be found in s/may be found/are defined/ src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 761: > 759: * "{@docRoot}/../specs/security/standard-names.html#signature-schemes"> > 760: * Signature Schemes section of the Java Security Standard Algorithm > 761: * Names Specification. Providers may support signature schemes not found s/found/defined/ src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 762: > 760: * Signature Schemes section of the Java Security Standard Algorithm > 761: * Names Specification. Providers may support signature schemes not found > 762: * in this list or might not use the recommended name for a certain s/might/may/ src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 766: > 764: * > 765: * @implSpec > 766: * This method will make a copy of the {@code signatureSchemes} array. Should be part of API specification (see my similar comment on `getSignatureSchemes`. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 769: > 767: * > 768: * @param signatureSchemes {@code null} or an ordered array of signature > 769: * scheme names, with the first entry being the most preferred. Suggest rewording as: "an ordered array of signature scheme names with the first entry being the most preferred, or {@null}." src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 770: > 768: * @param signatureSchemes {@code null} or an ordered array of signature > 769: * scheme names, with the first entry being the most preferred. > 770: * @throws IllegalArgumentException if any element in the non-empty I don't think the word "non-empty" is necessary as an empty array has no elements. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 786: > 784: if (scheme == null || scheme.isBlank()) { > 785: throw new IllegalArgumentException( > 786: "An element of signatureSchemes was null or blank"); s/was/is/ ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From mullan at openjdk.java.net Wed Feb 2 14:48:18 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 2 Feb 2022 14:48:18 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v2] In-Reply-To: <1GU_LQE4xPb-k02FTR5Hh-gqBhZTydgJsZf-7SwqY9M=.f972b0ea-0e93-4908-b890-7d57c26929d1@github.com> References: <1GU_LQE4xPb-k02FTR5Hh-gqBhZTydgJsZf-7SwqY9M=.f972b0ea-0e93-4908-b890-7d57c26929d1@github.com> Message-ID: On Tue, 1 Feb 2022 06:42:30 GMT, Xue-Lei Andrew Fan wrote: >> Ok. You should specify what the default value of the signature schemes parameter is for this constructor as it does for the other parameters. > > Good catch. Updated. Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From michaelm at openjdk.java.net Wed Feb 2 17:12:05 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 2 Feb 2022 17:12:05 GMT Subject: RFR: 8280868: LineBodyHandlerTest.java creates and discards too many clients In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 09:45:02 GMT, Daniel Fuchs wrote: > Please find enclosed a simple test fix for: > 8280868: LineBodyHandlerTest.java creates and discards too many clients > > The LineBodyHandlerTest.java creates and discards many clients (64). > The test has been observed failing intermittently on some systems (Windows 10) while trying to open the client's selector, apparently due to some connection limit. > > It seems that using a single client reduces the occurrences in which the test fails. LGTM ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7263 From dfuchs at openjdk.java.net Wed Feb 2 17:15:11 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Feb 2022 17:15:11 GMT Subject: Integrated: 8280868: LineBodyHandlerTest.java creates and discards too many clients In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 09:45:02 GMT, Daniel Fuchs wrote: > Please find enclosed a simple test fix for: > 8280868: LineBodyHandlerTest.java creates and discards too many clients > > The LineBodyHandlerTest.java creates and discards many clients (64). > The test has been observed failing intermittently on some systems (Windows 10) while trying to open the client's selector, apparently due to some connection limit. > > It seems that using a single client reduces the occurrences in which the test fails. This pull request has now been integrated. Changeset: 47800bf3 Author: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/47800bf3da181ae0ee612b14d95773fd1dc90350 Stats: 23 lines in 1 file changed: 19 ins; 0 del; 4 mod 8280868: LineBodyHandlerTest.java creates and discards too many clients Reviewed-by: michaelm ------------- PR: https://git.openjdk.java.net/jdk/pull/7263 From xuelei at openjdk.java.net Wed Feb 2 19:12:56 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 2 Feb 2022 19:12:56 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v9] In-Reply-To: References: Message-ID: > 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 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: More update for the sec and impl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/b5161f75..6b74767e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=07-08 Stats: 71 lines in 4 files changed: 22 ins; 14 del; 35 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 Feb 2 19:19:06 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 2 Feb 2022 19:19:06 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v8] In-Reply-To: References: Message-ID: <_tv1PlD90bJCcJvKWPx373BEvKUElF6AMnhKzH3GI9c=.11c1c252-2a33-412e-9355-a75d6b717402@github.com> On Wed, 2 Feb 2022 14:45:21 GMT, Sean Mullan wrote: > A few more comments on the API. All good catches! Thank you very much. Updated the spec, CSR and impl. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From kevinw at openjdk.java.net Wed Feb 2 21:42:40 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 2 Feb 2022 21:42:40 GMT Subject: RFR: 8272777: Clean up remaining AccessController warnings in test library Message-ID: Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied). ------------- Commit messages: - 8272777: Clean up remaining AccessController warnings in test library Changes: https://git.openjdk.java.net/jdk/pull/7328/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7328&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272777 Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7328/head:pull/7328 PR: https://git.openjdk.java.net/jdk/pull/7328 From mullan at openjdk.java.net Wed Feb 2 22:09:15 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 2 Feb 2022 22:09:15 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v9] In-Reply-To: References: Message-ID: <7Xyi3AzQOTsAW6xBtgnWviEyMZC0KGMmfeL_Vaw9qV0=.701cded7-5b72-4a65-8ca0-514469dde051@github.com> On Wed, 2 Feb 2022 19:12:56 GMT, Xue-Lei Andrew Fan 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 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > More update for the sec and impl Ok, great. I'll need another day or so to review the implementation changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From mullan at openjdk.java.net Wed Feb 2 22:16:07 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 2 Feb 2022 22:16:07 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v9] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 19:12:56 GMT, Xue-Lei Andrew Fan 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 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > More update for the sec and impl On a related issue, have you given any thought as to what the behavior should be if a 3rd-party JSSE provider is not updated to support these new methods? I don't know of a good way to address that since the API is not part of the provider implementation. We need a way to query what parameters a given provider supports, I think. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From rriggs at openjdk.java.net Wed Feb 2 22:20:06 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 2 Feb 2022 22:20:06 GMT Subject: RFR: 8272777: Clean up remaining AccessController warnings in test library In-Reply-To: References: Message-ID: <_L4Gi3dFyz96bvNUHDkT7IuStFCz3NzUG_gRvtvemNA=.ac833bfc-d84a-4ce0-9053-ed9b515858cc@github.com> On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls wrote: > Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied). Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7328 From xuelei at openjdk.java.net Wed Feb 2 22:31:16 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 2 Feb 2022 22:31:16 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v9] In-Reply-To: References: Message-ID: <_5H87ADjUIdbVDc-hGXOH-7NFPhG-IvYTw2auTKGnl0=.acd15baf-dfa4-4812-8130-300e851d98d8@github.com> On Wed, 2 Feb 2022 19:12:56 GMT, Xue-Lei Andrew Fan 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 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > More update for the sec and impl > ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Wed Feb 2 22:31:16 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 2 Feb 2022 22:31:16 GMT Subject: Withdrawn: 8280494: (D)TLS signature schemes In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 22:06:21 GMT, Xue-Lei Andrew Fan 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 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Wed Feb 2 22:45:14 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 2 Feb 2022 22:45:14 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v9] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 22:13:07 GMT, Sean Mullan wrote: > On a related issue, have you given any thought as to what the behavior should be if a 3rd-party JSSE provider is not updated to support these new methods? I don't know of a good way to address that since the API is not part of the provider implementation. We need a way to query what parameters a given provider supports, I think. It's a good question. A 3rd party provider need to support to the new APIs. Otherwise, the spec does not really work except to use the default values. It might be overweighted if the Java SE API has to detect the implementation details. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From sspitsyn at openjdk.java.net Wed Feb 2 22:56:16 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Feb 2022 22:56:16 GMT Subject: RFR: 8272777: Clean up remaining AccessController warnings in test library In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls wrote: > Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied). Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7328 From jboes at openjdk.java.net Thu Feb 3 09:31:38 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 3 Feb 2022 09:31:38 GMT Subject: RFR: 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 Message-ID: This change updates the tests in question to handle the case where sym link creation is not supported, as observed on Windows 11 where additional privileges are required to create sym links. Testing: tier 1-3 across platforms, plus tests in question on Windows 11 specifically ------------- Commit messages: - initial commit Changes: https://git.openjdk.java.net/jdk/pull/7335/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7335&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280965 Stats: 80 lines in 2 files changed: 32 ins; 4 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/7335.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7335/head:pull/7335 PR: https://git.openjdk.java.net/jdk/pull/7335 From kevinw at openjdk.java.net Thu Feb 3 10:14:14 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 3 Feb 2022 10:14:14 GMT Subject: RFR: 8272777: Clean up remaining AccessController warnings in test library In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls wrote: > Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied). Thanks Roger and Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/7328 From kevinw at openjdk.java.net Thu Feb 3 10:14:14 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 3 Feb 2022 10:14:14 GMT Subject: Integrated: 8272777: Clean up remaining AccessController warnings in test library In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls wrote: > Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied). This pull request has now been integrated. Changeset: 63a00a0d Author: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/63a00a0df24b154ef459936dbd69bcd2f0626235 Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod 8272777: Clean up remaining AccessController warnings in test library Reviewed-by: rriggs, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/7328 From duke at openjdk.java.net Thu Feb 3 11:22:57 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Thu, 3 Feb 2022 11:22:57 GMT Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs [v4] In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> Message-ID: > There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues : > JDK-8273142 > JDK-8268464 > JDK-8268133 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 four additional commits since the last revision: - Merge branch 'master' into JDK-8061729 - Implemented the review comments. - Implemented review comments. - JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5937/files - new: https://git.openjdk.java.net/jdk/pull/5937/files/b1b76be9..6f4b7d3a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=02-03 Stats: 1041549 lines in 4815 files changed: 560242 ins; 453231 del; 28076 mod Patch: https://git.openjdk.java.net/jdk/pull/5937.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5937/head:pull/5937 PR: https://git.openjdk.java.net/jdk/pull/5937 From dfuchs at openjdk.java.net Thu Feb 3 11:23:11 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 3 Feb 2022 11:23:11 GMT Subject: RFR: 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 09:24:46 GMT, Julia Boes wrote: > This change updates the tests in question to handle the case where sym link creation is not supported, as observed on Windows 11 where additional privileges are required to create sym links. > > Testing: tier 1-3 across platforms, plus tests in question on Windows 11 specifically test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java line 74: > 72: import jdk.test.lib.Platform; > 73: import jdk.test.lib.net.URIBuilder; > 74: import jtreg.SkippedException; Same remark here: You should use the testng exception instead - testng doesn't recognize the jtreg exception test/jdk/com/sun/net/httpserver/simpleserver/SimpleFileServerTest.java line 55: > 53: import jdk.test.lib.net.URIBuilder; > 54: import jdk.test.lib.util.FileUtils; > 55: import jtreg.SkippedException; You should use the testng exception instead - testng doesn't recognize the jtreg exception ------------- PR: https://git.openjdk.java.net/jdk/pull/7335 From josh at joshlong.com Thu Feb 3 00:07:51 2022 From: josh at joshlong.com (Josh Long) Date: Wed, 2 Feb 2022 16:07:51 -0800 Subject: possible to access the default DNS resolver for JEP 418 pass-thru resolution? Message-ID: hello, I'm very interested in JEP 418: Internet-Address Resolution SPI, and I was wondering: if I plugged in my own implementation via service loader, would it be possible to obtain a reference to the default implementation (the one that my implementation replaces) for pass-thru resolution? Ideally, var url = URl.create( "http://my-service/data") ; try (var in = url.openStream()){ // } would route through my implementation (which would know what to do with a non DNS entry like `my-service`) and then, if my implementation can't resolve, it gets resolved by the default system DNS resolver Thanks, Josh Long @starbuxman Spring Developer Advocate, Tanzu VMware http://BootifulPodcast.fm http://ReactiveSpring.io http://CloudNativeJava.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 3 12:08:57 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Feb 2022 12:08:57 +0000 Subject: possible to access the default DNS resolver for JEP 418 pass-thru resolution? In-Reply-To: References: Message-ID: On 03/02/2022 00:07, Josh Long wrote: > hello, > I'm very interested in JEP 418: Internet-Address Resolution SPI, and I > was wondering: if I plugged in my own implementation via service > loader, would it be possible to obtain a reference to the default > implementation (the one that my implementation replaces)?for pass-thru > resolution? > Yes, in the "Service-provider interface" section of the JEP it lists the new classes, one of which is Configuration that provides a reference to the built-in resolver. -Alan. From jpai at openjdk.java.net Thu Feb 3 12:35:51 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 3 Feb 2022 12:35:51 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v10] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: fix javadoc to mention HttpClient instead of HTTPClient ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6690/files - new: https://git.openjdk.java.net/jdk/pull/6690/files/c7e50bec..d06c7987 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=08-09 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 jpai at openjdk.java.net Thu Feb 3 12:35:55 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 3 Feb 2022 12:35:55 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v9] In-Reply-To: <6Gu0r4yrJiL47bEnzVKhuygrgAERCtLHLSmCa4Xr8Lw=.0f735454-164c-4d9b-8761-657ed0bf6dea@github.com> References: <6Gu0r4yrJiL47bEnzVKhuygrgAERCtLHLSmCa4Xr8Lw=.0f735454-164c-4d9b-8761-657ed0bf6dea@github.com> Message-ID: On Wed, 2 Feb 2022 10:37:54 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> minor - rename variable in test > > src/java.net.http/share/classes/java/net/http/HttpClient.java line 376: > >> 374: * correct {@code localAddr} is passed. Failure to do so can result in >> 375: * requests sent through the {@code HTTPClient} to fail. >> 376: * > > `{@code HTTPClient}` should probably `{@code HttpClient}` since that's how the class is named. You are right, that was an oversight. I've now fixed it in the latest update to this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/6690 From michaelm at openjdk.java.net Thu Feb 3 16:20:10 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 3 Feb 2022 16:20:10 GMT Subject: RFR: 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 09:24:46 GMT, Julia Boes wrote: > This change updates the tests in question to handle the case where sym link creation is not supported, as observed on Windows 11 where additional privileges are required to create sym links. > > Testing: tier 1-3 across platforms, plus tests in question on Windows 11 specifically test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java line 444: > 442: } > 443: > 444: private boolean createSymLink(Path symlink, Path target) { Seems like createSymLink should actually return true or false, or if it throws an exception in one case, then it should be void, in which case you wouldn't need the if statement in the calling code ------------- PR: https://git.openjdk.java.net/jdk/pull/7335 From jboes at openjdk.java.net Thu Feb 3 16:59:07 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 3 Feb 2022 16:59:07 GMT Subject: RFR: 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 16:16:32 GMT, Michael McMahon wrote: >> This change updates the tests in question to handle the case where sym link creation is not supported, as observed on Windows 11 where additional privileges are required to create sym links. >> >> Testing: tier 1-3 across platforms, plus tests in question on Windows 11 specifically > > test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java line 444: > >> 442: } >> 443: >> 444: private boolean createSymLink(Path symlink, Path target) { > > Seems like createSymLink should actually return true or false, or if it throws an exception in one case, then it should be void, in which case you wouldn't need the if statement in the calling code Good catch, that makes for cleaner code - I'll refactor. ------------- PR: https://git.openjdk.java.net/jdk/pull/7335 From mullan at openjdk.java.net Thu Feb 3 21:34:12 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 3 Feb 2022 21:34:12 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v9] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 22:41:56 GMT, Xue-Lei Andrew Fan wrote: > > On a related issue, have you given any thought as to what the behavior should be if a 3rd-party JSSE provider is not updated to support these new methods? I don't know of a good way to address that since the API is not part of the provider implementation. We need a way to query what parameters a given provider supports, I think. > > It's a good question. A 3rd party provider need to support to the new APIs. Otherwise, the spec does not really work except to use the default values. It might be overweighted if the Java SE API has to detect the implementation details. Fair point. However, I think then we have to make some changes to the specification wording that state that these new methods depend on support from the underlying provider. In other words something like `SSLParameters.setSignatureSchemes(new String[] {"ecdsa_secp521r1_sha512"})` could be silently ignored if the provider doesn't support the new method. It's unfortunate because a developer may miss this point or it may go undetected, whereas throwing an `UnsupportedOperationException` would probably be detected (but which won't work for this API). I do note that previous methods we have added to SSLParameters have probably had this same issue. But I think we should try to address it better with these methods. I'll suggest some wording changes. To help reduce this potential issue, we can make sure we mention this issue in the release notes, and encourage 3rd party providers to add support for these methods when they add support for JDK 18. Open to other ideas though. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Fri Feb 4 07:46:07 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 4 Feb 2022 07:46:07 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v9] In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 21:30:59 GMT, Sean Mullan wrote: > > > On a related issue, have you given any thought as to what the behavior should be if a 3rd-party JSSE provider is not updated to support these new methods? I don't know of a good way to address that since the API is not part of the provider implementation. We need a way to query what parameters a given provider supports, I think. > > > > > > It's a good question. A 3rd party provider need to support to the new APIs. Otherwise, the spec does not really work except to use the default values. It might be overweighted if the Java SE API has to detect the implementation details. > > Fair point. However, I think then we have to make some changes to the specification wording that state that these new methods depend on support from the underlying provider. In other words something like `SSLParameters.setSignatureSchemes(new String[] {"ecdsa_secp521r1_sha512"})` could be silently ignored if the provider doesn't support the new method. It's unfortunate because a developer may miss this point or it may go undetected, whereas throwing an `UnsupportedOperationException` would probably be detected (but which won't work for this API). I do note that previous methods we have added to SSLParameters have probably had this same issue. But I think we should try to address it better with these methods. I'll suggest some wording changes. > > To help reduce this potential issue, we can make sure we mention this issue in the release notes, and encourage 3rd party providers to add support for these methods when they add support for JDK 18. > > Open to other ideas though. Good points. I will try to add an apiNote. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From jboes at openjdk.java.net Fri Feb 4 09:44:53 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 4 Feb 2022 09:44:53 GMT Subject: RFR: 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 [v2] In-Reply-To: References: Message-ID: > This change updates the tests in question to handle the case where sym link creation is not supported, as observed on Windows 11 where additional privileges are required to create sym links. > > Testing: tier 1-3 across platforms, plus tests in question on Windows 11 specifically Julia Boes has updated the pull request incrementally with two additional commits since the last revision: - refactor test helper method - change jtreg.SkippedException to testng.SkipException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7335/files - new: https://git.openjdk.java.net/jdk/pull/7335/files/24836222..bd9c19d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7335&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7335&range=00-01 Stats: 64 lines in 2 files changed: 2 ins; 8 del; 54 mod Patch: https://git.openjdk.java.net/jdk/pull/7335.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7335/head:pull/7335 PR: https://git.openjdk.java.net/jdk/pull/7335 From dfuchs at openjdk.java.net Fri Feb 4 11:47:10 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 4 Feb 2022 11:47:10 GMT Subject: RFR: 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 [v2] In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 09:44:53 GMT, Julia Boes wrote: >> This change updates the tests in question to handle the case where sym link creation is not supported, as observed on Windows 11 where additional privileges are required to create sym links. >> >> Testing: tier 1-3 across platforms, plus tests in question on Windows 11 specifically > > Julia Boes has updated the pull request incrementally with two additional commits since the last revision: > > - refactor test helper method > - change jtreg.SkippedException to testng.SkipException Changes look good to me! ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7335 From michaelm at openjdk.java.net Fri Feb 4 13:19:26 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 4 Feb 2022 13:19:26 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable Message-ID: Hi, Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. The proposed property names are: "http.keepAlive.time.server" and "http.keepAlive.time.proxy" Thanks, Michael ------------- Commit messages: - added docs - reverted change to LIFETIME constant. Were not necessary - updates - Merge branch 'master' into keepalive - Merge branch 'master' into keepalive - Merge branch 'master' into keepalive - Merge branch 'master' into keepalive - Merge branch 'master' into keepalive - initial work Changes: https://git.openjdk.java.net/jdk/pull/7349/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7349&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278067 Stats: 252 lines in 4 files changed: 242 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7349/head:pull/7349 PR: https://git.openjdk.java.net/jdk/pull/7349 From dfuchs at openjdk.java.net Fri Feb 4 14:15:10 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 4 Feb 2022 14:15:10 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 13:11:02 GMT, Michael McMahon wrote: > Hi, > > Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) > > It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. > The proposed property names are: > > "http.keepAlive.time.server" and "http.keepAlive.time.proxy" > > Thanks, > Michael src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java line 159: > 157: int keepAliveTimeout = http.getKeepAliveTimeout(); > 158: if (keepAliveTimeout == 0) { > 159: keepAliveTimeout = getUserKeepAlive(http.getUsingProxy()); This could be 0 if -Dhttp.keepAlive.time.xxx=0 was specified which would result in an assert below. Also I am not sure I understand the logic of having same 5s timeout for server & proxy if nothing was specified anywhere, but having a different value for proxy & server if the server specified keep-alive without providing a value. Where does that come from? ------------- PR: https://git.openjdk.java.net/jdk/pull/7349 From michaelm at openjdk.java.net Fri Feb 4 15:20:13 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 4 Feb 2022 15:20:13 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable In-Reply-To: References: Message-ID: <4Ht13u8CD6i7OG0z6wqZJgRxmXVTOV-8bANGVbdeq30=.be56c85e-4551-49fa-8623-903ecaecd195@github.com> On Fri, 4 Feb 2022 14:11:49 GMT, Daniel Fuchs wrote: >> Hi, >> >> Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) >> >> It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. >> The proposed property names are: >> >> "http.keepAlive.time.server" and "http.keepAlive.time.proxy" >> >> Thanks, >> Michael > > src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java line 159: > >> 157: int keepAliveTimeout = http.getKeepAliveTimeout(); >> 158: if (keepAliveTimeout == 0) { >> 159: keepAliveTimeout = getUserKeepAlive(http.getUsingProxy()); > > This could be 0 if -Dhttp.keepAlive.time.xxx=0 was specified which would result in an assert below. > Also I am not sure I understand the logic of having same 5s timeout for server & proxy if nothing was specified anywhere, but having a different value for proxy & server if the server specified keep-alive without providing a value. > Where does that come from? Ah, I meant to catch that case as well in the method where the property is read. Probably should be documented as well. The other behavior is just maintaining the present behavior, purely for compatibility reasons. ------------- PR: https://git.openjdk.java.net/jdk/pull/7349 From mullan at openjdk.java.net Fri Feb 4 16:39:19 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 4 Feb 2022 16:39:19 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v9] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 19:12:56 GMT, Xue-Lei Andrew Fan 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 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > More update for the sec and impl Changes requested by mullan (Reviewer). src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 713: > 711: * in this list or may not use the recommended name for a certain > 712: * signature scheme. > 713: *

Regarding my previous comment about providers not supporting these new methods, I think something like the following might suffice: @apiNote Note that a provider may not have been updated to support this method and in that case may return null instead of the default signature schemes for pre-populated objects. @implNote The SunJSSE provider supports this method. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 735: > 733: * {@link #setSignatureSchemes} method has not been called, this method > 734: * should return the default signature schemes for connection populated > 735: * objects, or {@code null} for pre-populated objects. I think this sentence should be part of the specification and not the implementation note since ideally you would want all provider implementations to behave this way (assuming they supported this method): "If the {@link #setSignatureSchemes} method has not been called, this method should return the default signature schemes for connection populated objects, or {@code null} for pre-populated objects." src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 752: > 750: > 751: /** > 752: * Sets the prioritized array of signature scheme names that If the system properties are set, does it override this API? I think it is important to mention that here in an @implNote. I know you discuss them in `getSignatureSchemes` but I think a developer is more likely to want to know the behavior of the properties for this method especially if they will override this setting. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 761: > 759: * Names Specification. Providers may support signature schemes not defined > 760: * in this list or may not use the recommended name for a certain > 761: * signature scheme. Did you want to say something about what the behavior should be if a provider does not support one of these schemes? Is it ignored, or is an exception thrown? src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 762: > 760: * in this list or may not use the recommended name for a certain > 761: * signature scheme. > 762: * Regarding my previous comment about providers not supporting these new methods, I think something like the following might suffice: @apiNote Note that a provider may not have been updated to support this method and in that case may ignore the schemes that are set. @implNote The SunJSSE provider supports this method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Fri Feb 4 18:15:18 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 4 Feb 2022 18:15:18 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v10] In-Reply-To: References: Message-ID: > 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 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: More spec udpate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/6b74767e..9670efbd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=08-09 Stats: 39 lines in 2 files changed: 34 ins; 3 del; 2 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 Fri Feb 4 18:20:14 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 4 Feb 2022 18:20:14 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v9] In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 16:34:14 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> More update for the sec and impl > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 735: > >> 733: * {@link #setSignatureSchemes} method has not been called, this method >> 734: * should return the default signature schemes for connection populated >> 735: * objects, or {@code null} for pre-populated objects. > > I think this sentence should be part of the specification and not the implementation note since ideally you would want all provider implementations to behave this way (assuming they supported this method): > > "If the {@link #setSignatureSchemes} method has not been called, this method should return the default signature schemes for connection populated objects, or {@code null} for pre-populated objects." I agreed. > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 752: > >> 750: >> 751: /** >> 752: * Sets the prioritized array of signature scheme names that > > If the system properties are set, does it override this API? I think it is important to mention that here in an @implNote. I know you discuss them in `getSignatureSchemes` but I think a developer is more likely to want to know the behavior of the properties for this method especially if they will override this setting. I though it is a spec of the get method. But I agree with you that it could be helpful if we have it in the set method as well. Updated. > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 761: > >> 759: * Names Specification. Providers may support signature schemes not defined >> 760: * in this list or may not use the recommended name for a certain >> 761: * signature scheme. > > Did you want to say something about what the behavior should be if a provider does not support one of these schemes? Is it ignored, or is an exception thrown? Just as your suggested in a later comment, an apiNote was added. > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 762: > >> 760: * in this list or may not use the recommended name for a certain >> 761: * signature scheme. >> 762: * > > Regarding my previous comment about providers not supporting these new methods, I think something like the following might suffice: > > > @apiNote Note that a provider may not have been updated to support this method and in that case may ignore the schemes that are set. > @implNote The SunJSSE provider supports this method. Thank you for the suggestion. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Fri Feb 4 18:26:10 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 4 Feb 2022 18:26:10 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v11] In-Reply-To: References: Message-ID: > 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 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Add missed spec, and delete swp file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/9670efbd..70382768 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=09-10 Stats: 7 lines in 2 files changed: 7 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 Fri Feb 4 18:33:46 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 4 Feb 2022 18:33:46 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v12] In-Reply-To: References: Message-ID: > 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 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Correct the set spec ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/70382768..70c3755b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=10-11 Stats: 2 lines in 1 file changed: 1 ins; 0 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 Fri Feb 4 18:33:49 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 4 Feb 2022 18:33:49 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v9] In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 16:35:22 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> More update for the sec and impl > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 713: > >> 711: * in this list or may not use the recommended name for a certain >> 712: * signature scheme. >> 713: *

> > Regarding my previous comment about providers not supporting these new methods, I think something like the following might suffice: > > > @apiNote Note that a provider may not have been updated to support this method and in that case may return null instead of the default signature schemes for pre-populated objects. > @implNote The SunJSSE provider supports this method. It looks like a typo. Replaced "pre-populated objects" with "connection populated objects", and added to the spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Fri Feb 4 20:58:46 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 4 Feb 2022 20:58:46 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v13] In-Reply-To: References: Message-ID: > 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 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: correct null tags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/70c3755b..be947693 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=11-12 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 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 Fri Feb 4 23:08:32 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 4 Feb 2022 23:08:32 GMT Subject: RFR: 8281289: Improve with List.copyOf Message-ID: Please review this trivial code clean up, for a little bit better performance. ------------- Commit messages: - 8281289: Improve with List.copyOf Changes: https://git.openjdk.java.net/jdk/pull/7356/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7356&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281289 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7356.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7356/head:pull/7356 PR: https://git.openjdk.java.net/jdk/pull/7356 From jnimeh at openjdk.java.net Sat Feb 5 00:16:11 2022 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Sat, 5 Feb 2022 00:16:11 GMT Subject: RFR: 8281289: Improve with List.copyOf In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 23:02:21 GMT, Xue-Lei Andrew Fan wrote: > Please review this trivial code clean up, for a little bit better performance. Looks good to me. ------------- Marked as reviewed by jnimeh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7356 From hchao at openjdk.java.net Sat Feb 5 02:21:12 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Sat, 5 Feb 2022 02:21:12 GMT Subject: RFR: 8281289: Improve with List.copyOf In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 23:02:21 GMT, Xue-Lei Andrew Fan wrote: > Please review this trivial code clean up, for a little bit better performance. Marked as reviewed by hchao (Committer). Looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/7356 From xuelei at openjdk.java.net Sat Feb 5 07:49:18 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 5 Feb 2022 07:49:18 GMT Subject: Integrated: 8281289: Improve with List.copyOf In-Reply-To: References: Message-ID: <6sMS8ar3Ycy8lizlmln6RJ_rWCl4B0zUKEPywds8PS8=.6cf14dbf-b795-4f63-9030-a016dc66c7a7@github.com> On Fri, 4 Feb 2022 23:02:21 GMT, Xue-Lei Andrew Fan wrote: > Please review this trivial code clean up, for a little bit better performance. This pull request has now been integrated. Changeset: 42e272e1 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/42e272e181f188c89fa88f144715f19235943fca Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod 8281289: Improve with List.copyOf Reviewed-by: jnimeh, hchao ------------- PR: https://git.openjdk.java.net/jdk/pull/7356 From redestad at openjdk.java.net Sat Feb 5 13:25:12 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Sat, 5 Feb 2022 13:25:12 GMT Subject: RFR: 8281289: Improve with List.copyOf In-Reply-To: References: Message-ID: <7TsJR1VAUZRYopniWdA62B53Zif3V-vELI1PZ2jWgUI=.61c65ef7-872d-4733-b809-f7f53cb844e0@github.com> On Fri, 4 Feb 2022 23:02:21 GMT, Xue-Lei Andrew Fan wrote: > Please review this trivial code clean up, for a little bit better performance. There's a small compatibility risk with this change, e.g., `List.copyOf(...).contains(null)` will throw NPE while `Collections.unmodifiableList(...).contains(null)` won't. If we accept that compatibility risk (which should probably be decided by CSR) it might also make sense to use `List.of()` for the empty case, which will reduce the number of List implementation classes returned from the API. ------------- PR: https://git.openjdk.java.net/jdk/pull/7356 From xuelei at openjdk.java.net Sat Feb 5 20:34:10 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 5 Feb 2022 20:34:10 GMT Subject: RFR: 8281289: Improve with List.copyOf In-Reply-To: <7TsJR1VAUZRYopniWdA62B53Zif3V-vELI1PZ2jWgUI=.61c65ef7-872d-4733-b809-f7f53cb844e0@github.com> References: <7TsJR1VAUZRYopniWdA62B53Zif3V-vELI1PZ2jWgUI=.61c65ef7-872d-4733-b809-f7f53cb844e0@github.com> Message-ID: <-jTrCzKIxs7SZWrvqmtk6OH6PlA9XolGP_LYAQs00ZU=.8fab488c-8a77-4a4f-b9b4-f4b906f43c80@github.com> On Sat, 5 Feb 2022 13:22:25 GMT, Claes Redestad wrote: > There's a small compatibility risk with this change, e.g., `List.copyOf(...).contains(null)` will throw NPE while `Collections.unmodifiableList(...).contains(null)` won't. > > If we accept that compatibility risk (which should probably be decided by CSR) it might also make sense to use `List.of()` for the empty case, which will reduce the number of List implementation classes returned from the API. All GOOD points! Thanks! I filed a new JDK-8281298, and a new [pull request](https://github.com/openjdk/jdk/pull/7359). ------------- PR: https://git.openjdk.java.net/jdk/pull/7356 From xuelei at openjdk.java.net Sat Feb 5 20:36:36 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 5 Feb 2022 20:36:36 GMT Subject: RFR: 8281298: Revise the creation of unmodifiable list Message-ID: In [JDK-8281289](https://bugs.openjdk.java.net/browse/JDK-8281289), the SSLParameters class was updated with the patch: - return Collections.unmodifiableList(new ArrayList<>(sniNames.values())); + return List.copyOf(sniNames.values()); However, there's a small compatibility risk with this change, `List.copyOf(...).contains(null)` will throw NPE while `Collections.unmodifiableList(...).contains(null)` won't. It may be not worthy of the risk although the impact may be minimal. This update will re-use the Collections.unmodifiableList() methods, but re-org the code for better performance. ------------- Commit messages: - 8281298: Revise the creation of unmodifiable list Changes: https://git.openjdk.java.net/jdk/pull/7359/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7359&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281298 Stats: 71 lines in 1 file changed: 18 ins; 25 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/7359.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7359/head:pull/7359 PR: https://git.openjdk.java.net/jdk/pull/7359 From redestad at openjdk.java.net Sun Feb 6 22:14:11 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 6 Feb 2022 22:14:11 GMT Subject: RFR: 8281298: Revise the creation of unmodifiable list In-Reply-To: References: Message-ID: On Sat, 5 Feb 2022 20:29:50 GMT, Xue-Lei Andrew Fan wrote: > In [JDK-8281289](https://bugs.openjdk.java.net/browse/JDK-8281289), the SSLParameters class was updated with the patch: > > - return Collections.unmodifiableList(new ArrayList<>(sniNames.values())); > + return List.copyOf(sniNames.values()); > > However, there's a small compatibility risk with this change, `List.copyOf(...).contains(null)` will throw NPE while `Collections.unmodifiableList(...).contains(null)` won't. It may be not worthy of the risk although the impact may be minimal. > > This update will re-use the Collections.unmodifiableList() methods, but re-org the code for better performance. This looks like an appropriate solution which avoids the minor compatibility risk introduced by the previous change - and you might even end up being more efficient both when setting and reading the names/matchers. (Since we're going down the route of optimizing this: the `type` of a `SNIServerName` is constrained to a value between 0 and 255, so there's likely a small micro-optimization opportunity in using a `BitSet` for the duplicate checking rather a `ArrayList`.. A `BitSet(256)` should have lower memory use and the existence check will run in O(1) instead of O(n) time. Might not be worthwhile to optimize these setters, though..) ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7359 From xuelei at openjdk.java.net Mon Feb 7 05:52:06 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Feb 2022 05:52:06 GMT Subject: RFR: 8281298: Revise the creation of unmodifiable list In-Reply-To: References: Message-ID: On Sun, 6 Feb 2022 22:11:06 GMT, Claes Redestad wrote: > This looks like an appropriate solution which avoids the minor compatibility risk introduced by the previous change - and you might even end up being more efficient both when setting and reading the names/matchers. > > (Since we're going down the route of optimizing this: the `type` of a `SNIServerName` is constrained to a value between 0 and 255, so there's likely a small micro-optimization opportunity in using a `BitSet` for the duplicate checking rather a `ArrayList`.. A `BitSet(256)` should have lower memory use and the existence check will run in O(1) instead of O(n) time. Might not be worthwhile to optimize these setters, though..) Thank you for the quick review. As the number of SNIServerName is normally one in practice, I'm not very sure of the improvement to use BitSet yet. But I'm glad to know the BitSet could be a better choice if the items number goes beyond 4. ------------- PR: https://git.openjdk.java.net/jdk/pull/7359 From xuelei at openjdk.java.net Mon Feb 7 06:33:11 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Feb 2022 06:33:11 GMT Subject: Integrated: 8281298: Revise the creation of unmodifiable list In-Reply-To: References: Message-ID: On Sat, 5 Feb 2022 20:29:50 GMT, Xue-Lei Andrew Fan wrote: > In [JDK-8281289](https://bugs.openjdk.java.net/browse/JDK-8281289), the SSLParameters class was updated with the patch: > > - return Collections.unmodifiableList(new ArrayList<>(sniNames.values())); > + return List.copyOf(sniNames.values()); > > However, there's a small compatibility risk with this change, `List.copyOf(...).contains(null)` will throw NPE while `Collections.unmodifiableList(...).contains(null)` won't. It may be not worthy of the risk although the impact may be minimal. > > This update will re-use the Collections.unmodifiableList() methods, but re-org the code for better performance. This pull request has now been integrated. Changeset: f2302822 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/f2302822c0ef30fbf7cb4e31b8dc1513e9413a23 Stats: 71 lines in 1 file changed: 18 ins; 25 del; 28 mod 8281298: Revise the creation of unmodifiable list Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/7359 From djelinski at openjdk.java.net Mon Feb 7 09:14:51 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 7 Feb 2022 09:14:51 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v7] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6090/files - new: https://git.openjdk.java.net/jdk/pull/6090/files/98b40812..cdb86b5c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=05-06 Stats: 13 lines in 2 files changed: 12 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6090/head:pull/6090 PR: https://git.openjdk.java.net/jdk/pull/6090 From djelinski at openjdk.java.net Mon Feb 7 09:19:11 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 7 Feb 2022 09:19:11 GMT Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments [v4] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 08:15:46 GMT, Daniel Jeli?ski wrote: >> Why? >> No users of `enumInterfaces` rely on the value returned in the second parameter when `enumInterfaces` returns a negative result. The same is true for `getAllInterfacesAndAddresses`. >> The second parameter was NULL-initialized in a few places; this initialization was not necessary and I just removed it to avoid confusion. > > ahh... I see your point now. I missed a few cases where the returned value was referenced (free'd) even though the function failed. These should be fixed now. Added null-initialization of return values on function entry. ------------- PR: https://git.openjdk.java.net/jdk/pull/6090 From jboes at openjdk.java.net Mon Feb 7 09:32:14 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 7 Feb 2022 09:32:14 GMT Subject: Integrated: 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 09:24:46 GMT, Julia Boes wrote: > This change updates the tests in question to handle the case where sym link creation is not supported, as observed on Windows 11 where additional privileges are required to create sym links. > > Testing: tier 1-3 across platforms, plus tests in question on Windows 11 specifically This pull request has now been integrated. Changeset: f3e82426 Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/f3e8242683f6c729d89e2f49b0977889b4786f4a Stats: 28 lines in 2 files changed: 22 ins; 0 del; 6 mod 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/7335 From mullan at openjdk.java.net Mon Feb 7 20:03:14 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 7 Feb 2022 20:03:14 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v13] In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 20:58:46 GMT, Xue-Lei Andrew Fan 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 null tags Changes requested by mullan (Reviewer). src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 47: > 45: *

> 46: * SSLParameters can be created via the constructors in this class. > 47: * Objects can also be obtained using the {@code getSSLParameters()} Since you introduce the terms "pre-populated" and "connection populated" in the new methods, I think it would be useful to describe them up front in the summary, ex: `{@code SSLParameter} objects can be created via the constructors in this class, and can be described as pre-populated objects. {@code SSLParameter} objects can also be obtained using the ... , and can be described as connection populated objects." src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 744: > 742: * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or > 743: * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to > 744: * customize the provider-specific default signature schemes. This still doesn't say if the properties override the API. I would suggest adding a sentence: "If set, these properties will override the signature schemes returned by this method." Similar comment in `setSignatureSchemes`. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 747: > 745: * > 746: * @return an array of signature scheme {@code Strings} or {@code null} if > 747: * none have been set. For non-null returns, this method willu Typo, s/willu/will/ ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Mon Feb 7 22:03:19 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Feb 2022 22:03:19 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v13] In-Reply-To: References: Message-ID: <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com> On Mon, 7 Feb 2022 19:51:28 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> correct null tags > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 744: > >> 742: * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or >> 743: * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to >> 744: * customize the provider-specific default signature schemes. > > This still doesn't say if the properties override the API. I would suggest adding a sentence: "If set, these properties will override the signature schemes returned by this method." > > Similar comment in `setSignatureSchemes`. I think lines 714-816/723-725 describe the behavior already. I was hesitate to use "override", as the System Property values and the default signature schemes are not actually overrode. The default signature schemes are still there, and they are not just used for this specific connection, when the connection use the non-default values. It might be something like, "If the returned array of this method is not {@code null} or empty, the default signature schemes are not used, and signature schemes in the returned array of this method will be used instead". But I think it is a duplicate of lines 714-816/723-725 . ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Mon Feb 7 22:15:54 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Feb 2022 22:15:54 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v14] In-Reply-To: References: Message-ID: > 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: Update class summary ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/be947693..8302c592 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=12-13 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 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 Mon Feb 7 22:24:11 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Feb 2022 22:24:11 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v13] In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 19:59:32 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> correct null tags > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 47: > >> 45: *

>> 46: * SSLParameters can be created via the constructors in this class. >> 47: * Objects can also be obtained using the {@code getSSLParameters()} > > Since you introduce the terms "pre-populated" and "connection populated" in the new methods, I think it would be useful to describe them up front in the summary, ex: > > `{@code SSLParameter} objects can be created via the constructors in this class, and can be described as pre-populated objects. {@code SSLParameter} objects can also be obtained using the ... , and can be described as connection populated objects." Nice! It is something I want to add for quite a while, but never get a chance. The suggested description is really simple and great! Updated! > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 747: > >> 745: * >> 746: * @return an array of signature scheme {@code Strings} or {@code null} if >> 747: * none have been set. For non-null returns, this method willu > > Typo, s/willu/will/ Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From mullan at openjdk.java.net Mon Feb 7 22:24:12 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 7 Feb 2022 22:24:12 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v13] In-Reply-To: <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com> References: <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com> Message-ID: On Mon, 7 Feb 2022 22:00:21 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 744: >> >>> 742: * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or >>> 743: * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to >>> 744: * customize the provider-specific default signature schemes. >> >> This still doesn't say if the properties override the API. I would suggest adding a sentence: "If set, these properties will override the signature schemes returned by this method." >> >> Similar comment in `setSignatureSchemes`. > > I think lines 714-816/723-725 describe the behavior already. > > I was hesitate to use "override", as the System Property values and the default signature schemes are not actually overrode. The default signature schemes are still there, and they are not just used for this specific connection, when the connection use the non-default values. > > It might be something like, "If the returned array of this method is not {@code null} or empty, the default signature schemes are not used, and signature schemes in the returned array of this method will be used instead". But I think it is a duplicate of lines 714-816/723-725 . Sorry, you will have to bear with me as I am still not sure how it works - I want to know who wins, the API or the properties, if both are set and I can't find where it answers that above. Maybe I need to read the code. Are you maybe saying that this method returns the value of the system properties if they are set? ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Mon Feb 7 23:01:11 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Feb 2022 23:01:11 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v13] In-Reply-To: References: <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com> Message-ID: On Mon, 7 Feb 2022 22:18:03 GMT, Sean Mullan wrote: >> I think lines 714-816/723-725 describe the behavior already. >> >> I was hesitate to use "override", as the System Property values and the default signature schemes are not actually overrode. The default signature schemes are still there, and they are not just used for this specific connection, when the connection use the non-default values. >> >> It might be something like, "If the returned array of this method is not {@code null} or empty, the default signature schemes are not used, and signature schemes in the returned array of this method will be used instead". But I think it is a duplicate of lines 714-816/723-725 . > > Sorry, you will have to bear with me as I am still not sure how it works - I want to know who wins, the API or the properties, if both are set and I can't find where it answers that above. Maybe I need to read the code. Are you maybe saying that this method returns the value of the system properties if they are set? > "If set, these properties will override the signature schemes returned by this method." If I understand your ideas correctly, the behavior should be "the returned value of this method will override these properties", except the case if the returned value is null. But let me trying if I could understand the spec by myself. For the getSignatureSchemes() method's spec: * If the returned array is {@code null}, then the underlying * provider-specific default signature schemes will be used over the * SSL/TLS/DTLS connections. With the spec above, the API getSignatureSchemes() returns null, and the provider-specific default signature schemes will be used for the connection. As the properties could be used to customize the default signature schemes, the properties wins in this situation for your question. However, I would like to express that the default signature schemes win (See bellow about why I don't want to use the properties). * If the returned array is empty (zero-length), then the signature scheme * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and * the connections may not be able to be established if the negotiation * mechanism is required by a certain SSL/TLS/DTLS protocol. With the spec above, the API getSignatureSchemes() returns empty array, and no signature schemes will be used. The API wins, the default signature schemes are not used. *

* If the returned array is not {@code null} or empty (zero-length), * then the signature schemes in the returned array will be used over * the SSL/TLS/DTLS connections. With the spec above, the API getSignatureSchemes() returns non-null and non-empty, and the returned array will be used. The API wins, the default signature schemes are not used. * @implNote * Note that the underlying provider may define the default signature * schemes for each SSL/TLS/DTLS connection. Applications may also use * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to * customize the provider-specific default signature schemes. With the spec above, I could understand what are the default signature schemes, and how they could be customized with properties. So back to my question above, why I don't want to use the properties, and use the default signature schemes instead? We need to take care of three things: the properties, the API set values and the provider default values. If I use the properties values, I would have to describe the provider default values as well. As the properties values are used to set the provider default values, it should be sufficient to use the provider default values for the description in this context. What if both the properties and the APIs are set? The properties are used to set the provider default values, and the properties will change the provider default values. So we only need to consider the provider default values and the API, then I think we can refer to the 3 spec sections before the @implNote tag above. Simply, if both set, the API wins. Similar to the set method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Mon Feb 7 23:16:09 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Feb 2022 23:16:09 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v13] In-Reply-To: References: <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com> Message-ID: <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com> On Mon, 7 Feb 2022 22:56:45 GMT, Xue-Lei Andrew Fan wrote: >> Sorry, you will have to bear with me as I am still not sure how it works - I want to know who wins, the API or the properties, if both are set and I can't find where it answers that above. Maybe I need to read the code. Are you maybe saying that this method returns the value of the system properties if they are set? > >> "If set, these properties will override the signature schemes returned by this method." > > If I understand your ideas correctly, the behavior should be "the returned value of this method will override these properties", except the case if the returned value is null. > > But let me trying if I could understand the spec by myself. > > For the getSignatureSchemes() method's spec: > > * If the returned array is {@code null}, then the underlying > * provider-specific default signature schemes will be used over the > * SSL/TLS/DTLS connections. > > With the spec above, the API getSignatureSchemes() returns null, and the provider-specific default signature schemes will be used for the connection. As the properties could be used to customize the default signature schemes, the properties wins in this situation for your question. However, I would like to express that the default signature schemes win (See bellow about why I don't want to use the properties). > > > * If the returned array is empty (zero-length), then the signature scheme > * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and > * the connections may not be able to be established if the negotiation > * mechanism is required by a certain SSL/TLS/DTLS protocol. > > With the spec above, the API getSignatureSchemes() returns empty array, and no signature schemes will be used. The API wins, the default signature schemes are not used. > > > *

> * If the returned array is not {@code null} or empty (zero-length), > * then the signature schemes in the returned array will be used over > * the SSL/TLS/DTLS connections. > > With the spec above, the API getSignatureSchemes() returns non-null and non-empty, and the returned array will be used. The API wins, the default signature schemes are not used. > > > * @implNote > * Note that the underlying provider may define the default signature > * schemes for each SSL/TLS/DTLS connection. Applications may also use > * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or > * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to > * customize the provider-specific default signature schemes. > > With the spec above, I could understand what are the default signature schemes, and how they could be customized with properties. > > So back to my question above, why I don't want to use the properties, and use the default signature schemes instead? We need to take care of three things: the properties, the API set values and the provider default values. If I use the properties values, I would have to describe the provider default values as well. As the properties values are used to set the provider default values, it should be sufficient to use the provider default values for the description in this context. > > What if both the properties and the APIs are set? The properties are used to set the provider default values, and the properties will change the provider default values. So we only need to consider the provider default values and the API, then I think we can refer to the 3 spec sections before the @implNote tag above. Simply, if both set, the API wins. > > Similar to the set method. > > Please let me know if you are on the same page as well. I am open to make more changes if the spec is still not clear. > Are you maybe saying that this method returns the value of the system properties if they are set? The return value of this method depends on the following specs: * If the {@link #setSignatureSchemes} method has not been called, this * method should return the default signature schemes for connection * populated objects, or {@code null} for pre-populated objects. ``` If the setSignatureSchemes() method has been called, the get method will return the set values. I may miss this spec. But I think it is a common sense that the getter method returns the values set with setter method. Let me know if you would like to have an explicit clarification in the spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From myano at openjdk.java.net Tue Feb 8 07:49:08 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 8 Feb 2022 07:49:08 GMT Subject: RFR: 8279329: Remove hardcoded IPv4 available policy on Windows In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 12:32:13 GMT, Alan Bateman wrote: >> I added socket connection check same as IPv6_supported(). >> Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4 uninstall`), and set property `-Djava.net.preferIPv4Stack=true`, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is always set to 1(IPv4), because IPv4_supported() always returns TRUE. After applied this fix, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is set to 2(IPv6). >> It looks fine that IPv4_supported() returns FALSE. >> Would you review this fix? > > This looks okay although I assume just one part of the changes need to work in an IPv6-only environment. @AlanBateman @dfuch @AlekseiEfimov Could someone please commit this PR as a sponsor? ------------- PR: https://git.openjdk.java.net/jdk/pull/7317 From myano at openjdk.java.net Tue Feb 8 08:35:08 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 8 Feb 2022 08:35:08 GMT Subject: Integrated: 8279329: Remove hardcoded IPv4 available policy on Windows In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 08:31:08 GMT, Masanori Yano wrote: > I added socket connection check same as IPv6_supported(). > Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4 uninstall`), and set property `-Djava.net.preferIPv4Stack=true`, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is always set to 1(IPv4), because IPv4_supported() always returns TRUE. After applied this fix, java.net.InetAddress.PLATFORM_LOOKUP_POLICY.characteristics is set to 2(IPv6). > It looks fine that IPv4_supported() returns FALSE. > Would you review this fix? This pull request has now been integrated. Changeset: f2a9627c Author: Masanori Yano Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/f2a9627c05f9ef82eb83d8c1b9d4209bf42e7d8d Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8279329: Remove hardcoded IPv4 available policy on Windows Reviewed-by: djelinski, alanb, dfuchs, aefimov ------------- PR: https://git.openjdk.java.net/jdk/pull/7317 From mullan at openjdk.java.net Tue Feb 8 20:21:23 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 8 Feb 2022 20:21:23 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v13] In-Reply-To: <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com> References: <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com> <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com> Message-ID: On Mon, 7 Feb 2022 23:13:13 GMT, Xue-Lei Andrew Fan wrote: >>> "If set, these properties will override the signature schemes returned by this method." >> >> If I understand your ideas correctly, the behavior should be "the returned value of this method will override these properties", except the case if the returned value is null. >> >> But let me trying if I could understand the spec by myself. >> >> For the getSignatureSchemes() method's spec: >> >> * If the returned array is {@code null}, then the underlying >> * provider-specific default signature schemes will be used over the >> * SSL/TLS/DTLS connections. >> >> With the spec above, the API getSignatureSchemes() returns null, and the provider-specific default signature schemes will be used for the connection. As the properties could be used to customize the default signature schemes, the properties wins in this situation for your question. However, I would like to express that the default signature schemes win (See bellow about why I don't want to use the properties). >> >> >> * If the returned array is empty (zero-length), then the signature scheme >> * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and >> * the connections may not be able to be established if the negotiation >> * mechanism is required by a certain SSL/TLS/DTLS protocol. >> >> With the spec above, the API getSignatureSchemes() returns empty array, and no signature schemes will be used. The API wins, the default signature schemes are not used. >> >> >> *

>> * If the returned array is not {@code null} or empty (zero-length), >> * then the signature schemes in the returned array will be used over >> * the SSL/TLS/DTLS connections. >> >> With the spec above, the API getSignatureSchemes() returns non-null and non-empty, and the returned array will be used. The API wins, the default signature schemes are not used. >> >> >> * @implNote >> * Note that the underlying provider may define the default signature >> * schemes for each SSL/TLS/DTLS connection. Applications may also use >> * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or >> * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to >> * customize the provider-specific default signature schemes. >> >> With the spec above, I could understand what are the default signature schemes, and how they could be customized with properties. >> >> So back to my question above, why I don't want to use the properties, and use the default signature schemes instead? We need to take care of three things: the properties, the API set values and the provider default values. If I use the properties values, I would have to describe the provider default values as well. As the properties values are used to set the provider default values, it should be sufficient to use the provider default values for the description in this context. >> >> What if both the properties and the APIs are set? The properties are used to set the provider default values, and the properties will change the provider default values. So we only need to consider the provider default values and the API, then I think we can refer to the 3 spec sections before the @implNote tag above. Simply, if both set, the API wins. >> >> Similar to the set method. >> >> Please let me know if you are on the same page as well. I am open to make more changes if the spec is still not clear. > >> Are you maybe saying that this method returns the value of the system properties if they are set? > > The return value of this method depends on the following specs: > > * If the {@link #setSignatureSchemes} method has not been called, this > * method should return the default signature schemes for connection > * populated objects, or {@code null} for pre-populated objects. > ``` > > If the setSignatureSchemes() method has been called, the get method will return the set values. I may miss this spec. But I think it is a common sense that the getter method returns the values set with setter method. Let me know if you would like to have an explicit clarification in the spec. Ok, I get it now, the API wins if both are set. But I could not discern that from the current text. I think it is ok to be more clear about this. I suggest adding something like the following: "The set of signature schemes that will be used is determined in this order of preference: 1. explicitly set by application; 2. specified by system property; 3. specified by provider defaults. For example, setting the signature schemes in your application overrides settings specified in jdk.tls.client.SignatureSchemes or jdk.tls.client.SignatureSchemes, as well as JDK provider defaults." Does that accurately capture the implementation behavior? ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Tue Feb 8 23:39:16 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 8 Feb 2022 23:39:16 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v13] In-Reply-To: References: <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com> <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com> Message-ID: On Tue, 8 Feb 2022 20:18:20 GMT, Sean Mullan wrote: >>> Are you maybe saying that this method returns the value of the system properties if they are set? >> >> The return value of this method depends on the following specs: >> >> * If the {@link #setSignatureSchemes} method has not been called, this >> * method should return the default signature schemes for connection >> * populated objects, or {@code null} for pre-populated objects. >> ``` >> >> If the setSignatureSchemes() method has been called, the get method will return the set values. I may miss this spec. But I think it is a common sense that the getter method returns the values set with setter method. Let me know if you would like to have an explicit clarification in the spec. > > Ok, I get it now, the API wins if both are set. But I could not discern that from the current text. I think it is ok to be more clear about this. I suggest adding something like the following: > > "The set of signature schemes that will be used is determined in this order of preference: 1. explicitly set by application; 2. specified by system property; 3. specified by provider defaults. For example, setting the signature schemes in your application overrides settings specified in jdk.tls.client.SignatureSchemes or jdk.tls.server.SignatureSchemes, as well as JDK provider defaults." > > Does that accurately capture the implementation behavior? Basically, the suggestion captures the implementation behaviors correctly. To make it more accuracy, if we want to use it, we may need to consider more cases: 1. _explicitly set by application_, with null, empty or 1+ schemes. 2. _specified by system property_, with unset, empty or 1+ schemes. I think the description could be in the following logic: A. the system properties are used to customize the provider default schemes. B. If the API set it to null, use the the provider default schemes (including system properties customized default schemes). C. If the API set it to empty, don't use any schemes. D. if the API set it to 1+ scheme, use the API set schemes. With logic A, we don't have to describe both _system properties_ and the _provider default schemes_ each time when we talk about the interaction behaviors of them. And then we can simplify the 3 interactive factors into 2 factors. Here is the general 3 interactive factors: 1. the API. 2. the System properties. 3. the provider default. Here is set 1 of the 2 interactive factors: 1. The System properties; 2. the provider default. Here is set 2 of the 2 interactive factors: 1. the API 2. the provider default. Then, we could describe set 1 and set 2 individually. I think it is easier to understand. Then, we could have the sections accordingly. For A, we have (for set 1 of the 2 interactive factors): * @implNote * Note that the underlying provider may define the default signature * schemes for each SSL/TLS/DTLS connection. Applications may also use * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to * customize the provider-specific default signature schemes. ``` For B, we have (for set 2 of the 2 interactive factors): * If the returned array is {@code null}, then the underlying * provider-specific default signature schemes will be used over the * SSL/TLS/DTLS connections. For C, we have (for set 2 of the 2 interactive factors): * If the returned array is empty (zero-length), then the signature scheme * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and * the connections may not be able to be established if the negotiation * mechanism is required by a certain SSL/TLS/DTLS protocol. For D, we have (for set 2 of the 2 interactive factors): *

* If the returned array is not {@code null} or empty (zero-length), * then the signature schemes in the returned array will be used over * the SSL/TLS/DTLS connections. That's the current description we have. That's, in order to explain behavior of the null, empty and 1+ schemes setting, I cut the sentence into 4 sections above. I understand it could be confusing when multiple facts are involved. It may be clear if re-org the description. What do you think of the following descriptions? In the get method: *

* Note that the underlying provider may define the default signature schemes for * each SSL/TLS/DTLS connection. Applications may also use the {@systemProperty * jdk.tls.client.SignatureSchemes} and/or {@systemProperty * jdk.tls.server.SignatureSchemes} system properties to customize the * provider-specific default signature schemes. *

* The set of signature schemes that will be used over the SSL/TLS/DTLS * connections is determined by the returned array of this method and the * underlying provider-specific default signature schemes. *

* If the returned array is {@code null}, then the underlying * provider-specific default signature schemes will be used over the * SSL/TLS/DTLS connections. *

* If the returned array is empty (zero-length), then the signature scheme * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and * the connections may not be able to be established if the negotiation * mechanism is required by a certain SSL/TLS/DTLS protocol. *

* If the returned array is not {@code null} or empty (zero-length), * then the signature schemes in the returned array will be used over * the SSL/TLS/DTLS connections. and similarly, in the set method: *

* Note that the underlying provider may define the default signature * schemes for each SSL/TLS/DTLS connection. Applications may also use * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to * customize the provider-specific default signature schemes. *

* The set of signature schemes that will be used over the SSL/TLS/DTLS * connections is determined by the input parameter {@code signatureSchemes} array * and the underlying provider-specific default signature schemes. *

* If the input parameter {@code signatureSchemes} array is {@code null}, * then the underlying provider-specific default signature schemes will * be used over the SSL/TLS/DTLS connections. *

* If the input parameter {@code signatureSchemes} array is empty * (zero-length), then the signature scheme negotiation mechanism is * turned off for SSL/TLS/DTLS protocols, and the connections may not be * able to be established if the negotiation mechanism is required by a * certain SSL/TLS/DTLS protocol. *

* If the input parameter {@code signatureSchemes} array is not {@code null} * or empty (zero-length), then the signature schemes specified in the * {@code signatureSchemes} array will be used over the SSL/TLS/DTLS * connections. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From mullan at openjdk.java.net Wed Feb 9 14:36:10 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 9 Feb 2022 14:36:10 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v13] In-Reply-To: References: <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com> <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com> Message-ID: On Tue, 8 Feb 2022 23:36:05 GMT, Xue-Lei Andrew Fan wrote: >> Ok, I get it now, the API wins if both are set. But I could not discern that from the current text. I think it is ok to be more clear about this. I suggest adding something like the following: >> >> "The set of signature schemes that will be used is determined in this order of preference: 1. explicitly set by application; 2. specified by system property; 3. specified by provider defaults. For example, setting the signature schemes in your application overrides settings specified in jdk.tls.client.SignatureSchemes or jdk.tls.server.SignatureSchemes, as well as JDK provider defaults." >> >> Does that accurately capture the implementation behavior? > > Basically, the suggestion captures the implementation behaviors correctly. To make it more accuracy, if we want to use it, we may need to consider more cases: > 1. _explicitly set by application_, with null, empty or 1+ schemes. > 2. _specified by system property_, with unset, empty or 1+ schemes. > > I think the description could be in the following logic: > A. the system properties are used to customize the provider default schemes. > B. If the API set it to null, use the the provider default schemes (including system properties customized default schemes). > C. If the API set it to empty, don't use any schemes. > D. if the API set it to 1+ scheme, use the API set schemes. > > With logic A, we don't have to describe both _system properties_ and the _provider default schemes_ each time when we talk about the interaction behaviors of them. And then we can simplify the 3 interactive factors into 2 factors. > > Here is the general 3 interactive factors: > 1. the API. > 2. the System properties. > 3. the provider default. > > Here is set 1 of the 2 interactive factors: > 1. The System properties; > 2. the provider default. > > Here is set 2 of the 2 interactive factors: > 1. the API > 2. the provider default. > > Then, we could describe set 1 and set 2 individually. I think it is easier to understand. > > Then, we could have the sections accordingly. > For A, we have (for set 1 of the 2 interactive factors): > > * @implNote > * Note that the underlying provider may define the default signature > * schemes for each SSL/TLS/DTLS connection. Applications may also use > * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or > * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to > * customize the provider-specific default signature schemes. > ``` > > For B, we have (for set 2 of the 2 interactive factors): > > * If the returned array is {@code null}, then the underlying > * provider-specific default signature schemes will be used over the > * SSL/TLS/DTLS connections. > > > For C, we have (for set 2 of the 2 interactive factors): > > * If the returned array is empty (zero-length), then the signature scheme > * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and > * the connections may not be able to be established if the negotiation > * mechanism is required by a certain SSL/TLS/DTLS protocol. > > > For D, we have (for set 2 of the 2 interactive factors): > > *

> * If the returned array is not {@code null} or empty (zero-length), > * then the signature schemes in the returned array will be used over > * the SSL/TLS/DTLS connections. > > > That's the current description we have. That's, in order to explain behavior of the null, empty and 1+ schemes setting, I cut the sentence into 4 sections above. > > I understand it could be confusing when multiple facts are involved. It may be clear if re-org the description. What do you think of the following descriptions? > > In the get method: > > *

> * Note that the underlying provider may define the default signature schemes for > * each SSL/TLS/DTLS connection. Applications may also use the {@systemProperty > * jdk.tls.client.SignatureSchemes} and/or {@systemProperty > * jdk.tls.server.SignatureSchemes} system properties to customize the > * provider-specific default signature schemes. > *

> * The set of signature schemes that will be used over the SSL/TLS/DTLS > * connections is determined by the returned array of this method and the > * underlying provider-specific default signature schemes. > *

> * If the returned array is {@code null}, then the underlying > * provider-specific default signature schemes will be used over the > * SSL/TLS/DTLS connections. > *

> * If the returned array is empty (zero-length), then the signature scheme > * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and > * the connections may not be able to be established if the negotiation > * mechanism is required by a certain SSL/TLS/DTLS protocol. > *

> * If the returned array is not {@code null} or empty (zero-length), > * then the signature schemes in the returned array will be used over > * the SSL/TLS/DTLS connections. > > > and similarly, in the set method: > > *

> * Note that the underlying provider may define the default signature > * schemes for each SSL/TLS/DTLS connection. Applications may also use > * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or > * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to > * customize the provider-specific default signature schemes. > *

> * The set of signature schemes that will be used over the SSL/TLS/DTLS > * connections is determined by the input parameter {@code signatureSchemes} array > * and the underlying provider-specific default signature schemes. > *

> * If the input parameter {@code signatureSchemes} array is {@code null}, > * then the underlying provider-specific default signature schemes will > * be used over the SSL/TLS/DTLS connections. > *

> * If the input parameter {@code signatureSchemes} array is empty > * (zero-length), then the signature scheme negotiation mechanism is > * turned off for SSL/TLS/DTLS protocols, and the connections may not be > * able to be established if the negotiation mechanism is required by a > * certain SSL/TLS/DTLS protocol. > *

> * If the input parameter {@code signatureSchemes} array is not {@code null} > * or empty (zero-length), then the signature schemes specified in the > * {@code signatureSchemes} array will be used over the SSL/TLS/DTLS > * connections. I see your points. Were you proposing that this text would all be normative text? If so, I don't think that is correct, as the system properties are implementation specific. What might work is if you take the first paragraph and move it to the end of the text above as an @implNote: > * @implNote > * Note that the underlying provider may define the default signature > * schemes for each SSL/TLS/DTLS connection. Applications may also use > * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or > * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to > * customize the provider-specific default signature schemes. I would probably use the word "override" instead of "customize". Customize sounds like you can change some of the defaults and leave others in place. I think you should also consider adding this sentence to the end of each of the paragraphs when the input is an empty array or an array of 1+: "This parameter will override the underlying provider-specific default signature schemes." Finally, to avoid duplication of text, I would only add this text to the `setSignatureSchemes` method, and in the `getSignatureSchemes` method, add something like: "See {@link setSignatureSchemes} for specific details on how the parameters are used in SSL/TLS/DTLS connections." ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Wed Feb 9 18:24:56 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Feb 2022 18:24:56 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v15] In-Reply-To: References: Message-ID: > 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: Spec update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/8302c592..c0018c67 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=13-14 Stats: 31 lines in 1 file changed: 7 ins; 16 del; 8 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 Feb 9 18:33:15 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Feb 2022 18:33:15 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v13] In-Reply-To: References: <_tbfU8VLlFtHAD5V_hSPUScqAYsHy5d1T2oJZ5-7P2I=.fe692180-c3d6-4f6d-8863-539d6a8e6a98@github.com> <9p5fNcKq76YweQaK6xNAye2M2IepXiEB_q-wtQxw8vk=.d2495625-8ba2-4266-be11-c93a4c80dece@github.com> Message-ID: On Wed, 9 Feb 2022 14:33:11 GMT, Sean Mullan wrote: >> Basically, the suggestion captures the implementation behaviors correctly. To make it more accuracy, if we want to use it, we may need to consider more cases: >> 1. _explicitly set by application_, with null, empty or 1+ schemes. >> 2. _specified by system property_, with unset, empty or 1+ schemes. >> >> I think the description could be in the following logic: >> A. the system properties are used to customize the provider default schemes. >> B. If the API set it to null, use the the provider default schemes (including system properties customized default schemes). >> C. If the API set it to empty, don't use any schemes. >> D. if the API set it to 1+ scheme, use the API set schemes. >> >> With logic A, we don't have to describe both _system properties_ and the _provider default schemes_ each time when we talk about the interaction behaviors of them. And then we can simplify the 3 interactive factors into 2 factors. >> >> Here is the general 3 interactive factors: >> 1. the API. >> 2. the System properties. >> 3. the provider default. >> >> Here is set 1 of the 2 interactive factors: >> 1. The System properties; >> 2. the provider default. >> >> Here is set 2 of the 2 interactive factors: >> 1. the API >> 2. the provider default. >> >> Then, we could describe set 1 and set 2 individually. I think it is easier to understand. >> >> Then, we could have the sections accordingly. >> For A, we have (for set 1 of the 2 interactive factors): >> >> * @implNote >> * Note that the underlying provider may define the default signature >> * schemes for each SSL/TLS/DTLS connection. Applications may also use >> * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or >> * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to >> * customize the provider-specific default signature schemes. >> ``` >> >> For B, we have (for set 2 of the 2 interactive factors): >> >> * If the returned array is {@code null}, then the underlying >> * provider-specific default signature schemes will be used over the >> * SSL/TLS/DTLS connections. >> >> >> For C, we have (for set 2 of the 2 interactive factors): >> >> * If the returned array is empty (zero-length), then the signature scheme >> * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and >> * the connections may not be able to be established if the negotiation >> * mechanism is required by a certain SSL/TLS/DTLS protocol. >> >> >> For D, we have (for set 2 of the 2 interactive factors): >> >> *

>> * If the returned array is not {@code null} or empty (zero-length), >> * then the signature schemes in the returned array will be used over >> * the SSL/TLS/DTLS connections. >> >> >> That's the current description we have. That's, in order to explain behavior of the null, empty and 1+ schemes setting, I cut the sentence into 4 sections above. >> >> I understand it could be confusing when multiple facts are involved. It may be clear if re-org the description. What do you think of the following descriptions? >> >> In the get method: >> >> *

>> * Note that the underlying provider may define the default signature schemes for >> * each SSL/TLS/DTLS connection. Applications may also use the {@systemProperty >> * jdk.tls.client.SignatureSchemes} and/or {@systemProperty >> * jdk.tls.server.SignatureSchemes} system properties to customize the >> * provider-specific default signature schemes. >> *

>> * The set of signature schemes that will be used over the SSL/TLS/DTLS >> * connections is determined by the returned array of this method and the >> * underlying provider-specific default signature schemes. >> *

>> * If the returned array is {@code null}, then the underlying >> * provider-specific default signature schemes will be used over the >> * SSL/TLS/DTLS connections. >> *

>> * If the returned array is empty (zero-length), then the signature scheme >> * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and >> * the connections may not be able to be established if the negotiation >> * mechanism is required by a certain SSL/TLS/DTLS protocol. >> *

>> * If the returned array is not {@code null} or empty (zero-length), >> * then the signature schemes in the returned array will be used over >> * the SSL/TLS/DTLS connections. >> >> >> and similarly, in the set method: >> >> *

>> * Note that the underlying provider may define the default signature >> * schemes for each SSL/TLS/DTLS connection. Applications may also use >> * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or >> * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to >> * customize the provider-specific default signature schemes. >> *

>> * The set of signature schemes that will be used over the SSL/TLS/DTLS >> * connections is determined by the input parameter {@code signatureSchemes} array >> * and the underlying provider-specific default signature schemes. >> *

>> * If the input parameter {@code signatureSchemes} array is {@code null}, >> * then the underlying provider-specific default signature schemes will >> * be used over the SSL/TLS/DTLS connections. >> *

>> * If the input parameter {@code signatureSchemes} array is empty >> * (zero-length), then the signature scheme negotiation mechanism is >> * turned off for SSL/TLS/DTLS protocols, and the connections may not be >> * able to be established if the negotiation mechanism is required by a >> * certain SSL/TLS/DTLS protocol. >> *

>> * If the input parameter {@code signatureSchemes} array is not {@code null} >> * or empty (zero-length), then the signature schemes specified in the >> * {@code signatureSchemes} array will be used over the SSL/TLS/DTLS >> * connections. > > I see your points. Were you proposing that this text would all be normative text? If so, I don't think that is correct, as the system properties are implementation specific. What might work is if you take the first paragraph and move it to the end of the text above as an @implNote: > >> * @implNote >> * Note that the underlying provider may define the default signature >> * schemes for each SSL/TLS/DTLS connection. Applications may also use >> * the {@systemProperty jdk.tls.client.SignatureSchemes} and/or >> * {@systemProperty jdk.tls.server.SignatureSchemes} system properties to >> * customize the provider-specific default signature schemes. > > I would probably use the word "override" instead of "customize". Customize sounds like you can change some of the defaults and leave others in place. > > I think you should also consider adding this sentence to the end of each of the paragraphs when the input is an empty array or an array of 1+: "This parameter will override the underlying provider-specific default signature schemes." > > Finally, to avoid duplication of text, I would only add this text to the `setSignatureSchemes` method, and in the `getSignatureSchemes` method, add something like: "See {@link setSignatureSchemes} for specific details on how the parameters are used in SSL/TLS/DTLS connections." Thank you for the word-smithing. The use of signature schemes in the TLS implementation depends on the getSignatureSchemes() method. In the getSignatureSchemes() methods, there are more cases described such as the signature schemes for populated objects and pre-populated objects. So I have the text in the getSignatureSchemes(), and use the See-link in the setSignatureSchemes() instead. Both the PR and CSR were updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From mullan at openjdk.java.net Wed Feb 9 21:46:16 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 9 Feb 2022 21:46:16 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v15] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 18:24:56 GMT, Xue-Lei Andrew Fan 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: > > Spec update If you agree with my last couple of comments, I think the API looks good now that you can finalize the CSR. I have not really reviewed the impl code and tests previously and may not have time to do a thorough review although I think Jamil may have done that - if he is ok with the rest of the code, then I think you can integrate once the CSR is approved. Thanks for the patience. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 749: > 747: * @implNote > 748: * Note that the underlying provider may define the default signature > 749: * schemes for each SSL/TLS/DTLS connection. Applications may also use I think you can remove the first sentence that starts with "Note ..." as you already talk about provider-specific defaults before this. Also @implNotes are usually about the JDK implementation and not any provider. In the second sentence I would be more specific that this applies to the SunJSSE provider (see changes in italics), ex: "Applications ... system properties _with the SunJSSE provider_ to ..." ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Wed Feb 9 22:58:16 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Feb 2022 22:58:16 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v15] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 21:38:22 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Spec update > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 749: > >> 747: * @implNote >> 748: * Note that the underlying provider may define the default signature >> 749: * schemes for each SSL/TLS/DTLS connection. Applications may also use > > I think you can remove the first sentence that starts with "Note ..." as you already talk about provider-specific defaults before this. Also @implNotes are usually about the JDK implementation and not any provider. In the second sentence I would be more specific that this applies to the SunJSSE provider (see changes in italics), ex: "Applications ... system properties _with the SunJSSE provider_ to ..." Sounds good to me. Updated the CSR and PR. Thank you for the review! @jnimeh Jamil, do you have any comment about the spec and implementation? Otherwise, I will finalize the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Wed Feb 9 23:01:56 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Feb 2022 23:01:56 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v16] In-Reply-To: References: Message-ID: <9R1rEVErOxfA5_uNu32S4jJorF9UVltpfCqt6zeDiPs=.a973dde6-2c8b-4d72-bca2-1c1bdcfb55cc@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: spec re-wording ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/c0018c67..40163778 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=14-15 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 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 duke at openjdk.java.net Fri Feb 11 11:15:56 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Fri, 11 Feb 2022 11:15:56 GMT Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs [v5] In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> Message-ID: > There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues : > JDK-8273142 > JDK-8268464 > JDK-8268133 Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: 1. Handled continuation line 2. handled \r, \n, or \r\n 3. Added the test for HttpHeaderParser class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5937/files - new: https://git.openjdk.java.net/jdk/pull/5937/files/6f4b7d3a..70a37be9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=03-04 Stats: 857 lines in 11 files changed: 812 ins; 10 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/5937.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5937/head:pull/5937 PR: https://git.openjdk.java.net/jdk/pull/5937 From michaelm at openjdk.java.net Fri Feb 11 12:55:48 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 11 Feb 2022 12:55:48 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable [v2] In-Reply-To: References: Message-ID: <3oCNsR1nqUkHdKK47EjWnRjA8S3wSiwEnjSiHlGkXCs=.0fc0866d-2c88-4b2d-9bde-6b1a18f41b24@github.com> > Hi, > > Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) > > It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. > The proposed property names are: > > "http.keepAlive.time.server" and "http.keepAlive.time.proxy" > > Thanks, > 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 11 additional commits since the last revision: - update after Daniel's first review - Merge branch 'master' into keepalive - added docs - reverted change to LIFETIME constant. Were not necessary - updates - Merge branch 'master' into keepalive - Merge branch 'master' into keepalive - Merge branch 'master' into keepalive - Merge branch 'master' into keepalive - Merge branch 'master' into keepalive - ... and 1 more: https://git.openjdk.java.net/jdk/compare/98c4ce4c...edcbb13f ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7349/files - new: https://git.openjdk.java.net/jdk/pull/7349/files/85d5662b..edcbb13f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7349&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7349&range=00-01 Stats: 12764 lines in 314 files changed: 9568 ins; 1658 del; 1538 mod Patch: https://git.openjdk.java.net/jdk/pull/7349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7349/head:pull/7349 PR: https://git.openjdk.java.net/jdk/pull/7349 From michaelm at openjdk.java.net Mon Feb 14 11:20:56 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 14 Feb 2022 11:20:56 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable [v3] In-Reply-To: References: Message-ID: > Hi, > > Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) > > It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. > The proposed property names are: > > "http.keepAlive.time.server" and "http.keepAlive.time.proxy" > > Thanks, > 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 12 additional commits since the last revision: - Merge branch 'master' into keepalive - update after Daniel's first review - Merge branch 'master' into keepalive - added docs - reverted change to LIFETIME constant. Were not necessary - updates - Merge branch 'master' into keepalive - Merge branch 'master' into keepalive - Merge branch 'master' into keepalive - Merge branch 'master' into keepalive - ... and 2 more: https://git.openjdk.java.net/jdk/compare/7e38b27f...b0b7673c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7349/files - new: https://git.openjdk.java.net/jdk/pull/7349/files/edcbb13f..b0b7673c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7349&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7349&range=01-02 Stats: 3129 lines in 84 files changed: 2334 ins; 392 del; 403 mod Patch: https://git.openjdk.java.net/jdk/pull/7349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7349/head:pull/7349 PR: https://git.openjdk.java.net/jdk/pull/7349 From dfuchs at openjdk.java.net Mon Feb 14 13:42:11 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 14 Feb 2022 13:42:11 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable [v3] In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 11:20:56 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) >> >> It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. >> The proposed property names are: >> >> "http.keepAlive.time.server" and "http.keepAlive.time.proxy" >> >> Thanks, >> 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 12 additional commits since the last revision: > > - Merge branch 'master' into keepalive > - update after Daniel's first review > - Merge branch 'master' into keepalive > - added docs > - reverted change to LIFETIME constant. Were not necessary > - updates > - Merge branch 'master' into keepalive > - Merge branch 'master' into keepalive > - Merge branch 'master' into keepalive > - Merge branch 'master' into keepalive > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/de19266c...b0b7673c test/jdk/sun/net/www/http/KeepAliveCache/KeepAliveProperty.java line 111: > 109: out.print(BODY); > 110: out.flush(); > 111: pass = true; should that be: pass = ! expectClose? test/jdk/sun/net/www/http/KeepAliveCache/KeepAliveProperty.java line 125: > 123: > 124: static String fetch(URL url) throws Exception { > 125: InputStream in = url.openConnection(NO_PROXY).getInputStream(); could use try-with-resource here ------------- PR: https://git.openjdk.java.net/jdk/pull/7349 From duke at openjdk.java.net Mon Feb 14 18:03:16 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Mon, 14 Feb 2022 18:03:16 GMT Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs [v5] In-Reply-To: References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> Message-ID: On Fri, 11 Feb 2022 11:15:56 GMT, Mahendra Chhipa wrote: >> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues : >> JDK-8273142 >> JDK-8268464 >> JDK-8268133 > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > 1. Handled continuation line > 2. handled \r, \n, or \r\n > 3. Added the test for HttpHeaderParser class Mach5 results : https://mach5.us.oracle.com/mdash/jobs/mahendrachhipa-jdk-20220210-1911-29009006 ------------- PR: https://git.openjdk.java.net/jdk/pull/5937 From jpai at openjdk.java.net Tue Feb 15 06:25:03 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Feb 2022 06:25:03 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v11] In-Reply-To: References: Message-ID: <-C_7wQTgeYCSL-E_wH_8ZCIFuwkkDlHV81OMoE-_EE4=.d626fc6d-ec0a-4149-9e4e-5902c7427fe7@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 25 additional commits since the last revision: - 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 - By default add SocketPermission for java.net.http module to allow binding to non-ephemeral ports if local bind address is configured for HTTPClient - Merge latest master branch - Merge latest from master branch - ... and 15 more: https://git.openjdk.java.net/jdk/compare/a2286a47...11c1c6f2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6690/files - new: https://git.openjdk.java.net/jdk/pull/6690/files/d06c7987..11c1c6f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=09-10 Stats: 17815 lines in 512 files changed: 13263 ins; 2378 del; 2174 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 Tue Feb 15 13:15:06 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Feb 2022 13:15:06 GMT Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs [v5] In-Reply-To: References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> Message-ID: On Fri, 11 Feb 2022 11:15:56 GMT, Mahendra Chhipa wrote: >> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues : >> JDK-8273142 >> JDK-8268464 >> JDK-8268133 > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > 1. Handled continuation line > 2. handled \r, \n, or \r\n > 3. Added the test for HttpHeaderParser class test/lib/jdk/test/lib/net/HttpHeaderParser.java line 100: > 98: public List getHeaderValue(String key) { > 99: if(headerMap.containsKey(key.toLowerCase())) { > 100: return headerMap.get(key.toLowerCase()); I'd suggest to use `key.toLowerCase(Locale.ROOT)` - even though it shouldn't really matter if it's guaranteed that keys have been syntactically checked for illegal characters. test/lib/jdk/test/lib/net/HttpHeaderParser.java line 120: > 118: * ( when true is returned ), which may not be fully consumed. > 119: * > 120: * @param input the ( partial ) header data It doesn't look like this is a accurate. There's no ByteBuffers anywhere... test/lib/jdk/test/lib/net/HttpHeaderParser.java line 148: > 146: case FINISHED -> false; > 147: case STATUS_LINE_FOUND_LF, STATUS_LINE_END_LF, HEADER_FOUND_LF -> true; > 148: default -> buffer.available() >= 0; It's a bit chancy to use InputStream.available() - it would be better to have some `eof` variable that's set to true when EOF is reached, and return `!eof` here test/lib/jdk/test/lib/net/HttpHeaderParser.java line 162: > 160: * value from [0, 255] representing the character code. > 161: * > 162: * @param input a {@code ByteBuffer} containing a partial input Input is not a ByteBuffer and it doesn't contain a partial input. test/lib/jdk/test/lib/net/HttpHeaderParser.java line 171: > 169: private char get(InputStream input) throws IOException { > 170: return (char)(input.read() & 0xFF); > 171: } That doesn't look right as it will prevent you to read EOF. Maybe it should be: boolean eof; ... private int get(InputStream input) throws IOException { int c = input.read(); if (c < 0) eof = true; return c; } And then you would have to check for EOF everywhere where `get(input)` is called too. test/lib/jdk/test/lib/net/HttpHeaderParser.java line 175: > 173: private void readResumeStatusLine(InputStream input) throws IOException { > 174: char c = 0; > 175: while (input.available() > 0 && (c = get(input)) != CR) { It's not a too good idea to depend on input.available() - the spec leaves too much room for odd behaviors. https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/InputStream.html#available() An implementation may decide to return 0 always - as it is the amount of bytes that is guaranteed to be readable without blocking (and an implementation may not know how many bytes can be read without blocking). ------------- PR: https://git.openjdk.java.net/jdk/pull/5937 From michaelm at openjdk.java.net Tue Feb 15 13:30:41 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 15 Feb 2022 13:30:41 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable [v3] In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 13:38:06 GMT, Daniel Fuchs wrote: >> 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 12 additional commits since the last revision: >> >> - Merge branch 'master' into keepalive >> - update after Daniel's first review >> - Merge branch 'master' into keepalive >> - added docs >> - reverted change to LIFETIME constant. Were not necessary >> - updates >> - Merge branch 'master' into keepalive >> - Merge branch 'master' into keepalive >> - Merge branch 'master' into keepalive >> - Merge branch 'master' into keepalive >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/2fc8366a...b0b7673c > > test/jdk/sun/net/www/http/KeepAliveCache/KeepAliveProperty.java line 111: > >> 109: out.print(BODY); >> 110: out.flush(); >> 111: pass = true; > > should that be: pass = ! expectClose? Good catch. That was masking another problem in the test where it wasn't detecting the socket close properly. > test/jdk/sun/net/www/http/KeepAliveCache/KeepAliveProperty.java line 125: > >> 123: >> 124: static String fetch(URL url) throws Exception { >> 125: InputStream in = url.openConnection(NO_PROXY).getInputStream(); > > could use try-with-resource here Ok ------------- PR: https://git.openjdk.java.net/jdk/pull/7349 From michaelm at openjdk.java.net Tue Feb 15 13:30:35 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 15 Feb 2022 13:30:35 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable [v4] In-Reply-To: References: Message-ID: <_8dU-gkJIxxq7JDl8t876wU72XVMa82rGo79MC0LF1s=.c0825f9b-698b-4946-9bd4-2f28ca789d19@github.com> > Hi, > > Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) > > It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. > The proposed property names are: > > "http.keepAlive.time.server" and "http.keepAlive.time.proxy" > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: Fixed test case problem and update from Daniel's review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7349/files - new: https://git.openjdk.java.net/jdk/pull/7349/files/b0b7673c..79f64a76 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7349&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7349&range=02-03 Stats: 22 lines in 1 file changed: 5 ins; 6 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7349/head:pull/7349 PR: https://git.openjdk.java.net/jdk/pull/7349 From dfuchs at openjdk.java.net Tue Feb 15 13:38:09 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Feb 2022 13:38:09 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable [v4] In-Reply-To: <_8dU-gkJIxxq7JDl8t876wU72XVMa82rGo79MC0LF1s=.c0825f9b-698b-4946-9bd4-2f28ca789d19@github.com> References: <_8dU-gkJIxxq7JDl8t876wU72XVMa82rGo79MC0LF1s=.c0825f9b-698b-4946-9bd4-2f28ca789d19@github.com> Message-ID: <-Y0LXwzXOgd6zMAYezO3QsQLot0yuCitWu7vTtODABQ=.c70ba428-96f4-466c-905a-bca0a4f5402a@github.com> On Tue, 15 Feb 2022 13:30:35 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) >> >> It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. >> The proposed property names are: >> >> "http.keepAlive.time.server" and "http.keepAlive.time.proxy" >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test case problem and update from Daniel's review Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7349 From ccleary at openjdk.java.net Tue Feb 15 15:02:29 2022 From: ccleary at openjdk.java.net (Conor Cleary) Date: Tue, 15 Feb 2022 15:02:29 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. Message-ID: 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 ------------- Commit messages: - 8281223: Improve the API documentation of HttpRequest.Builder::build to state that the default implementation provided by the JDK returns immutable objects. Changes: https://git.openjdk.java.net/jdk/pull/7479/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7479&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281223 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7479/head:pull/7479 PR: https://git.openjdk.java.net/jdk/pull/7479 From dfuchs at openjdk.java.net Tue Feb 15 15:07:14 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Feb 2022 15:07:14 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. In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 14:05:16 GMT, Conor Cleary 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 src/java.net.http/share/classes/java/net/http/HttpRequest.java line 297: > 295: * @implSpec Returns a new {@code HttpRequest} each time it is > 296: * invoked. Once built, the HttpRequest is immutable and can be > 297: * sent multiple times. Looks fine to me. Maybe "This method returns ..." would more appropriate for an `@implSpec`. Also the second mention of `HttpRequest` should also have `{@code }` around it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7479 From michaelm at openjdk.java.net Tue Feb 15 15:23:03 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 15 Feb 2022 15:23:03 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable [v5] In-Reply-To: References: Message-ID: <0_0RCahnE9dzenD4VX8VeXnKdyIz0y7bKDTtUxKcBBI=.ccb9479a-ca4d-4de4-a03d-33bdbf07ed57@github.com> > Hi, > > Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) > > It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. > The proposed property names are: > > "http.keepAlive.time.server" and "http.keepAlive.time.proxy" > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: tighten up spec wording and move props beside existing keep alive ones ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7349/files - new: https://git.openjdk.java.net/jdk/pull/7349/files/79f64a76..9a7a4ced Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7349&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7349&range=03-04 Stats: 18 lines in 2 files changed: 10 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7349/head:pull/7349 PR: https://git.openjdk.java.net/jdk/pull/7349 From dfuchs at openjdk.java.net Tue Feb 15 15:23:03 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Feb 2022 15:23:03 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable [v5] In-Reply-To: <0_0RCahnE9dzenD4VX8VeXnKdyIz0y7bKDTtUxKcBBI=.ccb9479a-ca4d-4de4-a03d-33bdbf07ed57@github.com> References: <0_0RCahnE9dzenD4VX8VeXnKdyIz0y7bKDTtUxKcBBI=.ccb9479a-ca4d-4de4-a03d-33bdbf07ed57@github.com> Message-ID: On Tue, 15 Feb 2022 15:18:46 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) >> >> It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. >> The proposed property names are: >> >> "http.keepAlive.time.server" and "http.keepAlive.time.proxy" >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > tighten up spec wording and move props beside existing keep alive ones Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7349 From ccleary at openjdk.java.net Tue Feb 15 15:26:09 2022 From: ccleary at openjdk.java.net (Conor Cleary) Date: Tue, 15 Feb 2022 15:26:09 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. In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 15:04:12 GMT, Daniel Fuchs 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 > > src/java.net.http/share/classes/java/net/http/HttpRequest.java line 297: > >> 295: * @implSpec Returns a new {@code HttpRequest} each time it is >> 296: * invoked. Once built, the HttpRequest is immutable and can be >> 297: * sent multiple times. > > Looks fine to me. Maybe "This method returns ..." would more appropriate for an `@implSpec`. Also the second mention of `HttpRequest` should also have `{@code }` around it. Agree with both statements. "This method returns..." adds additional clarity and the additional {@code } was left out in error. Will correct now. ------------- PR: https://git.openjdk.java.net/jdk/pull/7479 From michaelm at openjdk.java.net Tue Feb 15 15:30:07 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 15 Feb 2022 15:30:07 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable [v6] In-Reply-To: References: Message-ID: > Hi, > > Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) > > It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. > The proposed property names are: > > "http.keepAlive.time.server" and "http.keepAlive.time.proxy" > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: remove extraneous .swp file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7349/files - new: https://git.openjdk.java.net/jdk/pull/7349/files/9a7a4ced..d047808e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7349&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7349&range=04-05 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7349/head:pull/7349 PR: https://git.openjdk.java.net/jdk/pull/7349 From ccleary at openjdk.java.net Tue Feb 15 15:33:01 2022 From: ccleary at openjdk.java.net (Conor Cleary) Date: Tue, 15 Feb 2022 15:33:01 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: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7479/files - new: https://git.openjdk.java.net/jdk/pull/7479/files/1bead0bd..bfc1de70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7479&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7479&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7479/head:pull/7479 PR: https://git.openjdk.java.net/jdk/pull/7479 From dfuchs at openjdk.java.net Tue Feb 15 15:47:13 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Feb 2022 15:47:13 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: References: Message-ID: <-BP5ke7wfuVIBZZlUvDoGKWLxxYD137ge56pTaNjUFo=.cca5cd47-6a90-48d2-8a73-f114eb1f0048@github.com> On Tue, 15 Feb 2022 15:33:01 GMT, Conor Cleary 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 dfuchs at openjdk.java.net Tue Feb 15 15:48:05 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Feb 2022 15:48:05 GMT Subject: RFR: 8278067: Make HttpURLConnection default keep alive timeout configurable [v6] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 15:30:07 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) >> >> It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. >> The proposed property names are: >> >> "http.keepAlive.time.server" and "http.keepAlive.time.proxy" >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > remove extraneous .swp file Good catch! I'd missed that. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7349 From jboes at openjdk.java.net Tue Feb 15 16:15:40 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 15 Feb 2022 16:15:40 GMT Subject: RFR: 8281305: Test com/sun/net/httpserver/simpleserver/MapToPathTest.java fails on Windows 11 Message-ID: This change adds a check for URI path segments that look like a root drive on Windows, e.g. "C:". Such path segments are not supported because a request path should really be relative to the working directory. The check is implemented with a platform-specific helper class, some additional test cases are included. Testing: tier 1-3, common Windows versions. ------------- Commit messages: - initial commit Changes: https://git.openjdk.java.net/jdk/pull/7478/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7478&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281305 Stats: 138 lines in 4 files changed: 131 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7478/head:pull/7478 PR: https://git.openjdk.java.net/jdk/pull/7478 From jboes at openjdk.java.net Wed Feb 16 09:05:46 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 16 Feb 2022 09:05:46 GMT Subject: RFR: 8281305: Test com/sun/net/httpserver/simpleserver/MapToPathTest.java fails on Windows 11 [v2] In-Reply-To: References: Message-ID: > This change adds a check for URI path segments that look like a root drive on Windows, e.g. "C:". Such path segments are not supported because a request path should really be relative to the working directory. > > The check is implemented with a platform-specific helper class, some additional test cases are included. > > Testing: tier 1-3, common Windows versions. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: fix package hierarchy ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7478/files - new: https://git.openjdk.java.net/jdk/pull/7478/files/8a2b738b..a6ef6934 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7478&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7478&range=00-01 Stats: 0 lines in 2 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7478/head:pull/7478 PR: https://git.openjdk.java.net/jdk/pull/7478 From dfuchs at openjdk.java.net Wed Feb 16 09:42:09 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 16 Feb 2022 09:42:09 GMT Subject: RFR: 8281305: Test com/sun/net/httpserver/simpleserver/MapToPathTest.java fails on Windows 11 [v2] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 09:05:46 GMT, Julia Boes wrote: >> This change adds a check for URI path segments that look like a root drive on Windows, e.g. "C:". Such path segments are not supported because a request path should really be relative to the working directory. >> >> The check is implemented with a platform-specific helper class, some additional test cases are included. >> >> Testing: tier 1-3, common Windows versions. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > fix package hierarchy LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7478 From duke at openjdk.java.net Wed Feb 16 13:55:43 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Wed, 16 Feb 2022 13:55:43 GMT Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs [v6] In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> Message-ID: > There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues : > JDK-8273142 > JDK-8268464 > JDK-8268133 Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments : 1. Use of Locale.ROOT 2. Rewritten get(InputStream is) method as per comments. 3. Corrected java doc comments. 4. Removed use of is.available() method. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5937/files - new: https://git.openjdk.java.net/jdk/pull/5937/files/70a37be9..6820c0cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=04-05 Stats: 112 lines in 1 file changed: 19 ins; 15 del; 78 mod Patch: https://git.openjdk.java.net/jdk/pull/5937.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5937/head:pull/5937 PR: https://git.openjdk.java.net/jdk/pull/5937 From duke at openjdk.java.net Wed Feb 16 14:37:07 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Wed, 16 Feb 2022 14:37:07 GMT Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs [v6] In-Reply-To: References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> Message-ID: <4Am85l8vDkYyDVHwNcHMDsd2xBp6AC4U1DPNkhYy9zs=.33422476-7064-4363-bb1e-0e2b6955a389@github.com> On Wed, 16 Feb 2022 13:55:43 GMT, Mahendra Chhipa wrote: >> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues : >> JDK-8273142 >> JDK-8268464 >> JDK-8268133 > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments : > 1. Use of Locale.ROOT > 2. Rewritten get(InputStream is) method as per comments. > 3. Corrected java doc comments. > 4. Removed use of is.available() method. Mach5 results https://mach5.us.oracle.com/mdash/jobs/mahendrachhipa-jdk-20220216-1342-29188746 ------------- PR: https://git.openjdk.java.net/jdk/pull/5937 From dfuchs at openjdk.java.net Wed Feb 16 15:29:12 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 16 Feb 2022 15:29:12 GMT Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs [v6] In-Reply-To: References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> Message-ID: <8vP1xmQsYLKFlbLUCF3uyEmlpdMI3xAIdFx55WyQucE=.e13c30e6-b123-40d3-a1d1-6d9972fa8a10@github.com> On Wed, 16 Feb 2022 13:55:43 GMT, Mahendra Chhipa wrote: >> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues : >> JDK-8273142 >> JDK-8268464 >> JDK-8268133 > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments : > 1. Use of Locale.ROOT > 2. Rewritten get(InputStream is) method as per comments. > 3. Corrected java doc comments. > 4. Removed use of is.available() method. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5937 From michaelm at openjdk.java.net Wed Feb 16 16:05:18 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 16 Feb 2022 16:05:18 GMT Subject: Integrated: 8278067: Make HttpURLConnection default keep alive timeout configurable In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 13:11:02 GMT, Michael McMahon wrote: > Hi, > > Could I get the following patch reviewed please? (A CSR is also required which I will submit when the docs are agreed) > > It adds a pair of new system properties to make the keep alive timer in java.net.HttpURLConnection configurable. > The proposed property names are: > > "http.keepAlive.time.server" and "http.keepAlive.time.proxy" > > Thanks, > Michael This pull request has now been integrated. Changeset: d8f44aa3 Author: Michael McMahon URL: https://git.openjdk.java.net/jdk/commit/d8f44aa39e921594505864e6270f42b745265293 Stats: 262 lines in 4 files changed: 249 ins; 1 del; 12 mod 8278067: Make HttpURLConnection default keep alive timeout configurable Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/7349 From duke at openjdk.java.net Wed Feb 16 16:48:14 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Wed, 16 Feb 2022 16:48:14 GMT Subject: Integrated: JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com> Message-ID: On Wed, 13 Oct 2021 22:04:23 GMT, Mahendra Chhipa wrote: > There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues : > JDK-8273142 > JDK-8268464 > JDK-8268133 This pull request has now been integrated. Changeset: 0f3d3ac3 Author: Mahendra Chhipa Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/0f3d3ac32c9d163a5d91c6839d313111c72f1ad4 Stats: 978 lines in 11 files changed: 921 ins; 12 del; 45 mod 8061729: Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5937 From xuelei at openjdk.java.net Wed Feb 16 19:21:58 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 16 Feb 2022 19:21:58 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v17] In-Reply-To: References: Message-ID: > 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 implSpec about existence of the new methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/40163778..bbc3bb8e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=15-16 Stats: 15 lines in 1 file changed: 12 ins; 1 del; 2 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 Feb 16 19:27:10 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 16 Feb 2022 19:27:10 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v17] In-Reply-To: References: Message-ID: <32Itvpr0Xo1s9gbqxdY54lXhuB8YUpWoyKdPuCGYYYo=.4161e44f-492f-48dd-9a70-d6b4f79ece1a@github.com> On Wed, 16 Feb 2022 19:21:58 GMT, Xue-Lei Andrew Fan 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 implSpec about existence of the new methods Joe had a good point in the CSR review for the existence of the new APIs in subclass SSLParameters. It is suggested to add a implSpec tag accordingly. May I have the CSR and SSLParameters spec update reviewed again? ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From dfuchs at openjdk.java.net Wed Feb 16 21:16:21 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 16 Feb 2022 21:16:21 GMT Subject: RFR: 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:10:41 GMT, Daniel Fuchs wrote: > A seemingly innocuous change from [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a test failure. The fix is to simply revert that small change. I am currently running tier2 tests in the CI ------------- PR: https://git.openjdk.java.net/jdk/pull/7503 From dfuchs at openjdk.java.net Wed Feb 16 21:16:21 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 16 Feb 2022 21:16:21 GMT Subject: RFR: 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" Message-ID: A seemingly innocuous change from [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a test failure. The fix is to simply revert that small change. ------------- Commit messages: - 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" Changes: https://git.openjdk.java.net/jdk/pull/7503/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7503&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282017 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7503.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7503/head:pull/7503 PR: https://git.openjdk.java.net/jdk/pull/7503 From dfuchs at openjdk.java.net Wed Feb 16 21:42:24 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 16 Feb 2022 21:42:24 GMT Subject: Integrated: 8282020: ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed Message-ID: Please find here a changeset to ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed ------------- Commit messages: - ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed Changes: https://git.openjdk.java.net/jdk/pull/7505/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7505&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282020 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7505/head:pull/7505 PR: https://git.openjdk.java.net/jdk/pull/7505 From michaelm at openjdk.java.net Wed Feb 16 21:42:24 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 16 Feb 2022 21:42:24 GMT Subject: Integrated: 8282020: ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:27:40 GMT, Daniel Fuchs wrote: > Please find here a changeset to ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed LGTM ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7505 From naoto at openjdk.java.net Wed Feb 16 21:42:25 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Feb 2022 21:42:25 GMT Subject: Integrated: 8282020: ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:27:40 GMT, Daniel Fuchs wrote: > Please find here a changeset to ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7505 From dfuchs at openjdk.java.net Wed Feb 16 21:42:25 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 16 Feb 2022 21:42:25 GMT Subject: Integrated: 8282020: ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed In-Reply-To: References: Message-ID: <_rw6hXdybS-471Ja5adWKQsX7YXgSk7IPcIj6fyoHy0=.f143bda8-ad2d-42c9-ae5e-75e7144b9efc@github.com> On Wed, 16 Feb 2022 21:27:40 GMT, Daniel Fuchs wrote: > Please find here a changeset to ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed This pull request has now been integrated. Changeset: 48f6e930 Author: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/48f6e93079f377a621ca769b820fa221062ceab1 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8282020: ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed Reviewed-by: michaelm, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/7505 From dfuchs at openjdk.java.net Wed Feb 16 21:49:47 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 16 Feb 2022 21:49:47 GMT Subject: RFR: 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" [v2] In-Reply-To: References: Message-ID: > A seemingly innocuous change from [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a test failure. The fix is to simply revert that small change. 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: - remove sun/net/www/protocol/https/HttpsURLConnection/B6216082.java from ProblemList - Merge branch 'master' into B6216082 - 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7503/files - new: https://git.openjdk.java.net/jdk/pull/7503/files/671fc22b..4f7f9454 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7503&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7503&range=00-01 Stats: 305 lines in 14 files changed: 286 ins; 14 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7503.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7503/head:pull/7503 PR: https://git.openjdk.java.net/jdk/pull/7503 From jboes at openjdk.java.net Thu Feb 17 10:41:09 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 17 Feb 2022 10:41:09 GMT Subject: Integrated: 8281305: Test com/sun/net/httpserver/simpleserver/MapToPathTest.java fails on Windows 11 In-Reply-To: References: Message-ID: <2TBh1lx09w75urmeeLBDYK_8Cfaqx80dUjhTfzgIFYs=.985b5701-3e8d-4da6-949d-7c5283bbd43e@github.com> On Tue, 15 Feb 2022 13:06:29 GMT, Julia Boes wrote: > This change adds a check for URI path segments that look like a root drive on Windows, e.g. "C:". Such path segments are not supported because a request path should really be relative to the working directory. > > The check is implemented with a platform-specific helper class, some additional test cases are included. > > Testing: tier 1-3, common Windows versions. This pull request has now been integrated. Changeset: 9ca435b4 Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/9ca435b4c03f9741709bbfab22fb006de8c8c9d3 Stats: 138 lines in 4 files changed: 131 ins; 0 del; 7 mod 8281305: Test com/sun/net/httpserver/simpleserver/MapToPathTest.java fails on Windows 11 Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/7478 From duke at openjdk.java.net Thu Feb 17 17:21:36 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Thu, 17 Feb 2022 17:21:36 GMT Subject: RFR: JDK-8282017 : sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" Message-ID: Updated TunnelProxy to avoid twice read of Request line. ------------- Commit messages: - JDK-8282017 : sun/net/www/protocol/https/HttpsURLConnection/B6216082.java Changes: https://git.openjdk.java.net/jdk/pull/7519/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7519&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282017 Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7519/head:pull/7519 PR: https://git.openjdk.java.net/jdk/pull/7519 From dfuchs at openjdk.java.net Thu Feb 17 17:35:12 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 17 Feb 2022 17:35:12 GMT Subject: RFR: JDK-8282017 : sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" In-Reply-To: References: Message-ID: <1vlU0C37AbrMo-nnD2KW5pU5vje0zqxBS2iIyV3l_vw=.656d0f63-0c3c-4ba7-b945-5ef52e3ae3e5@github.com> On Thu, 17 Feb 2022 17:13:38 GMT, Mahendra Chhipa wrote: > Updated TunnelProxy to avoid twice read of Request line. Looks good to me Mahendra. I will withdraw my own PR. Just make sure to run the whole of tier2 :-) ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7519 From duke at openjdk.java.net Thu Feb 17 17:35:12 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Thu, 17 Feb 2022 17:35:12 GMT Subject: RFR: JDK-8282017 : sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 17:13:38 GMT, Mahendra Chhipa wrote: > Updated TunnelProxy to avoid twice read of Request line. tier 2 mach5 Job : https://mach5.us.oracle.com/mdash/jobs/mahendrachhipa-jdk-20220217-1608-29227569 ------------- PR: https://git.openjdk.java.net/jdk/pull/7519 From dfuchs at openjdk.java.net Thu Feb 17 17:36:21 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 17 Feb 2022 17:36:21 GMT Subject: Withdrawn: 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:10:41 GMT, Daniel Fuchs wrote: > A seemingly innocuous change from [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a test failure. The fix is to simply revert that small change. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7503 From dfuchs at openjdk.java.net Thu Feb 17 17:36:21 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 17 Feb 2022 17:36:21 GMT Subject: RFR: 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" [v2] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:49:47 GMT, Daniel Fuchs wrote: >> A seemingly innocuous change from [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a test failure. The fix is to simply revert that small change. > > 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: > > - remove sun/net/www/protocol/https/HttpsURLConnection/B6216082.java from ProblemList > - Merge branch 'master' into B6216082 > - 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" I talked with @mahendrachhipa who has suggested a better fix. Closing this PR as a result. See https://github.com/openjdk/jdk/pull/7519 ------------- PR: https://git.openjdk.java.net/jdk/pull/7503 From duke at openjdk.java.net Thu Feb 17 17:49:08 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Thu, 17 Feb 2022 17:49:08 GMT Subject: Integrated: JDK-8282017 : sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 17:13:38 GMT, Mahendra Chhipa wrote: > Updated TunnelProxy to avoid twice read of Request line. This pull request has now been integrated. Changeset: cd9a3cf0 Author: Mahendra Chhipa Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/cd9a3cf05b2c200709103e2e8596414a62a1c441 Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/7519 From xuelei at openjdk.java.net Thu Feb 17 18:57:02 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 17 Feb 2022 18:57:02 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v18] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/bbc3bb8e..5a98c921 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=16-17 Stats: 15 lines in 1 file changed: 1 ins; 12 del; 2 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 jpai at openjdk.java.net Mon Feb 21 11:29:48 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 21 Feb 2022 11:29:48 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v12] In-Reply-To: References: Message-ID: <6huZVg5zcyXlbjM9RAj4ClmymBQtyWQIh2E9NThuXCI=.d3e0a3c1-5f9e-4802-839f-fe69fef0b53c@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 26 additional commits since the last revision: - 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 - By default add SocketPermission for java.net.http module to allow binding to non-ephemeral ports if local bind address is configured for HTTPClient - Merge latest master branch - ... and 16 more: https://git.openjdk.java.net/jdk/compare/a7140142...73010886 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6690/files - new: https://git.openjdk.java.net/jdk/pull/6690/files/11c1c6f2..73010886 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=10-11 Stats: 11241 lines in 256 files changed: 7560 ins; 2393 del; 1288 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 xuelei at openjdk.java.net Wed Feb 23 20:23:12 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 23 Feb 2022 20:23:12 GMT Subject: RFR: 8273042: TLS Certificate Compression Message-ID: Hi, Please review the implementation of RFC 8879, TLS Certificate Compression, in JDK. The TLS Certificate Compression standard is an essential part for QUIC connections and performance improvement for TLS connections. More details, please refer to the [JEP](https://bugs.openjdk.java.net/browse/JDK-8281710) proposal. The JEP was submitted, and it may take time for the final approval. But let me know you ideas and concerns about the proposal and implementation. JEP: https://bugs.openjdk.java.net/browse/JDK-8281710 ------------- Commit messages: - Merge - Describe public APIs - test and httpclient - 8273042: TLS Certificate Compression - Merge - Merge - Merge - 8273042: TLS Certificate Compression Changes: https://git.openjdk.java.net/jdk/pull/7599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7599&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273042 Stats: 1822 lines in 17 files changed: 1796 ins; 16 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7599/head:pull/7599 PR: https://git.openjdk.java.net/jdk/pull/7599 From duke at openjdk.java.net Thu Feb 24 16:09:23 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Thu, 24 Feb 2022 16:09:23 GMT Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer, HttpTransaction, HttpCallback from open/test/jdk/ tests Message-ID: 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 ------------- Commit messages: - 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 - Initial Version Changes: https://git.openjdk.java.net/jdk/pull/7616/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282354 Stats: 1573 lines in 11 files changed: 129 ins; 1346 del; 98 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 jboes at openjdk.java.net Fri Feb 25 08:43:04 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 25 Feb 2022 08:43:04 GMT Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer, HttpTransaction, HttpCallback from open/test/jdk/ tests In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 16:01:57 GMT, Mahendra Chhipa 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 test/jdk/java/net/ProxySelector/LoopbackAddresses.java line 78: > 76: // hard guarantee. > 77: server = HttpServer.create(new InetSocketAddress(loopback, 0), 10); > 78: server.createContext("/", new LoopbackAddresses()); While here, we could use the new [HttpServer::create](https://download.java.net/java/early_access/jdk18/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpServer.html#create(java.net.InetSocketAddress,int,java.lang.String,com.sun.net.httpserver.HttpHandler,com.sun.net.httpserver.Filter...)) overload that creates a server with a context (applies to all tests touched.) I also wonder if it would make sense to change the names of the classes that implement HttpHandler to "xyzHandler" for readability, and to create a separate class for the handler instead of using the test class. ------------- PR: https://git.openjdk.java.net/jdk/pull/7616 From duke at openjdk.java.net Fri Feb 25 14:58:34 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Fri, 25 Feb 2022 14:58:34 GMT Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer, HttpTransaction, HttpCallback from open/test/jdk/ tests [v2] In-Reply-To: References: Message-ID: > 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/5a05b077..ab79e48e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=00-01 Stats: 210 lines in 6 files changed: 100 ins; 92 del; 18 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 Feb 25 15:06:29 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Fri, 25 Feb 2022 15:06:29 GMT Subject: RFR: JDK-8282354 : Remove dependancy of TestHttpServer, HttpTransaction, HttpCallback from open/test/jdk/ tests [v3] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7616/files - new: https://git.openjdk.java.net/jdk/pull/7616/files/ab79e48e..d62ba21c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7616&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 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 Sat Feb 26 16:34:46 2022 From: duke at openjdk.java.net (Michael Felt) Date: Sat, 26 Feb 2022 16:34:46 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: <5y5gwE0TSqocIcNHMJ5eAv1ide0nprgLWAujlQUqqfI=.bd904290-6d89-47d9-87c4-90c4d9983af1@github.com> References: <5y5gwE0TSqocIcNHMJ5eAv1ide0nprgLWAujlQUqqfI=.bd904290-6d89-47d9-87c4-90c4d9983af1@github.com> Message-ID: On Fri, 28 Jan 2022 15:15:06 GMT, Daniel Fuchs wrote: > From the description and evaluation of [JDK-7163874](https://bugs.openjdk.java.net/browse/JDK-7163874) it seems that skipping this test on AIX would be reasonable. > > Some operating systems seem to accept 0.0.0.0 as input - and reply with 127.0.0.1. The changes made for JDK-7163874 simply makes sure that such a reply is not rejected as invalid on the ground that the received address is not the same as the input address. If 0.0.0.0 is not a valid input for the underlying operating system, then the test has no object and should probably be skipped. Being a bit more specific - especially re: valid address: - On AIX ping ::0 is not valid aixtools at x064:[aixtools]ping ::0 ping: bind: The socket name is not available on this system. - On AIX ping 0.0.0.0 is not invalid, but how it responds ETH: ====( 98 bytes transmitted on interface en0 )==== 16:13:13.970131171 ETH: [ 00:21:5e:a3:c7:44 -> 44:4e:6d:fa:4b:fe ] type 800 (IP) IP: < SRC = 192.168.129.64 > (x064) IP: < DST = 0.0.0.0 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=63721, ip_off=0 IP: ip_ttl=255, ip_sum=80d6, ip_p = 1 (ICMP) ICMP: icmp_type=8 (ECHO_REQUEST) icmp_id=216 icmp_seq=516 - In special cases - when there are devices external to the (virtual) machine, that respond to 0.0.0.0 you get the address of the replying device: root at p8-java1-adopt07:[/root]ping 0.0.0.0 PING 0.0.0.0 (0.0.0.0): 56 data bytes 64 bytes from 140.211.9.1: icmp_seq=0 ttl=255 time=11 ms 64 bytes from 140.211.9.1: icmp_seq=1 ttl=255 time=12 ms 64 bytes from 140.211.9.1: icmp_seq=2 ttl=255 time=0 ms - At trace level: ETH: ====( 98 bytes transmitted on interface en1 )==== 16:19:39.475020041 ETH: [ 12:31:9e:0f:73:03 -> 58:bc:27:ae:b0:50 ] type 800 (IP) IP: < SRC = 140.211.9.168 > (p8-java1-adopt07) IP: < DST = 0.0.0.0 > IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=23686, ip_off=0 IP: ip_ttl=255, ip_sum=c8a7, ip_p = 1 (ICMP) ICMP: icmp_type=8 (ECHO_REQUEST) icmp_id=238 icmp_seq=18 ETH: ====( 98 bytes received on interface en1 )==== 16:19:39.475356474 ETH: [ 58:bc:27:ae:b0:50 -> 12:31:9e:0f:73:03 ] type 800 (IP) IP: < SRC = 140.211.9.1 > (corv-car1-gw.nero.net) IP: < DST = 140.211.9.168 > (p8-java1-adopt07) IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=23686, ip_off=0 IP: ip_ttl=255, ip_sum=32d3, ip_p = 1 (ICMP) ICMP: icmp_type=0 (ECHO_REPLY) icmp_id=238 icmp_seq=18 In conclusion: the `solution` is most likely to skip the test, just as it is skipped for Windows. a) address `::0` is not valid b) a response to IPv4: 0.0.0.0 depends on an external device responding to `0.0.0.0` I'll make the basic changes - but I am sure to need help with text (the right bug number, or whatever) that needs to go into the code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From duke at openjdk.java.net Sat Feb 26 16:51:52 2022 From: duke at openjdk.java.net (Michael Felt) Date: Sat, 26 Feb 2022 16:51:52 GMT Subject: RFR: JDK-8280498: [aix]: jdk/java/net/Inet4Address/PingThis.java fails In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 15:56:07 GMT, Michael Felt wrote: > with IP "0.0.0.0" > > - it either does nothing and ping fails, or, in some virtual environments > is treated as the default route address. > - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted > as a vaild psuedo IPv6 address. '::1' must be used instead. > > ping: bind: The socket name is not available on this system. > ping: bind: The socket name is not available on this system. > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max = 0/0/0 ms > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > > > A long commit message. > > This came to light because some systems failed with IPv4 (those that passed > replaced 0.0.0.0 with the default router. but most just fail - not substituting > 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 > which compares well with other platform's behavior. - Was on vacation, and other life events. - Changes made, please review again. ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From duke at openjdk.java.net Sun Feb 27 13:50:30 2022 From: duke at openjdk.java.net (Michael Felt) Date: Sun, 27 Feb 2022 13:50:30 GMT Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on AIX [v2] In-Reply-To: References: Message-ID: > with IP "0.0.0.0" > > - it either does nothing and ping fails, or, in some virtual environments > is treated as the default route address. > - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted > as a vaild psuedo IPv6 address. '::1' must be used instead. > > ping: bind: The socket name is not available on this system. > ping: bind: The socket name is not available on this system. > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max = 0/0/0 ms > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > > > A long commit message. > > This came to light because some systems failed with IPv4 (those that passed > replaced 0.0.0.0 with the default router. but most just fail - not substituting > 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 > which compares well with other platform's behavior. Michael Felt has updated the pull request incrementally with one additional commit since the last revision: 8280498: AIX does not respond internally to 0.0.0.0; ::0 is invalid - skip test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7013/files - new: https://git.openjdk.java.net/jdk/pull/7013/files/8e86a15d..c4f1d7b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7013&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7013&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7013.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7013/head:pull/7013 PR: https://git.openjdk.java.net/jdk/pull/7013 From duke at openjdk.java.net Sun Feb 27 14:11:28 2022 From: duke at openjdk.java.net (Michael Felt) Date: Sun, 27 Feb 2022 14:11:28 GMT Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on AIX [v3] In-Reply-To: References: Message-ID: > with IP "0.0.0.0" > > - it either does nothing and ping fails, or, in some virtual environments > is treated as the default route address. > - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted > as a vaild psuedo IPv6 address. '::1' must be used instead. > > ping: bind: The socket name is not available on this system. > ping: bind: The socket name is not available on this system. > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max = 0/0/0 ms > PING ::1: (::1): 56 data bytes > 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms > 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms > > --- ::1 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > > > A long commit message. > > This came to light because some systems failed with IPv4 (those that passed > replaced 0.0.0.0 with the default router. but most just fail - not substituting > 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 > which compares well with other platform's behavior. Michael Felt has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8280498: skip test because: AIX does not respond internally to 0.0.0.0; ::0 is invalid ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7013/files - new: https://git.openjdk.java.net/jdk/pull/7013/files/c4f1d7b5..a972d32b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7013&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7013&range=01-02 Stats: 13 lines in 1 file changed: 0 ins; 11 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7013.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7013/head:pull/7013 PR: https://git.openjdk.java.net/jdk/pull/7013 From duke at openjdk.java.net Sun Feb 27 14:11:30 2022 From: duke at openjdk.java.net (Michael Felt) Date: Sun, 27 Feb 2022 14:11:30 GMT Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on AIX [v2] In-Reply-To: References: Message-ID: <0HCJI6idObe2Kkfy13TOuKJx5ueMNKDIx-cv6CErV_E=.d2a4a2a1-b717-4dd1-8e8f-abfddcafefdc@github.com> On Sun, 27 Feb 2022 13:50:30 GMT, Michael Felt wrote: >> with IP "0.0.0.0" >> >> - it either does nothing and ping fails, or, in some virtual environments >> is treated as the default route address. >> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted >> as a vaild psuedo IPv6 address. '::1' must be used instead. >> >> ping: bind: The socket name is not available on this system. >> ping: bind: The socket name is not available on this system. >> PING ::1: (::1): 56 data bytes >> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms >> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms >> >> --- ::1 ping statistics --- >> 2 packets transmitted, 2 packets received, 0% packet loss >> round-trip min/avg/max = 0/0/0 ms >> PING ::1: (::1): 56 data bytes >> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms >> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms >> >> --- ::1 ping statistics --- >> 2 packets transmitted, 2 packets received, 0% packet loss >> >> >> A long commit message. >> >> This came to light because some systems failed with IPv4 (those that passed >> replaced 0.0.0.0 with the default router. but most just fail - not substituting >> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 >> which compares well with other platform's behavior. > > Michael Felt has updated the pull request incrementally with one additional commit since the last revision: > > 8280498: AIX does not respond internally to 0.0.0.0; ::0 is invalid - skip test Force pushed - too many typos - so 'erased' the mess-ups ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From alanb at openjdk.java.net Sun Feb 27 16:42:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 27 Feb 2022 16:42:45 GMT Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on AIX [v3] In-Reply-To: References: Message-ID: On Sun, 27 Feb 2022 14:11:28 GMT, Michael Felt wrote: >> with IP "0.0.0.0" >> >> - it either does nothing and ping fails, or, in some virtual environments >> is treated as the default route address. >> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted >> as a vaild psuedo IPv6 address. '::1' must be used instead. >> >> ping: bind: The socket name is not available on this system. >> ping: bind: The socket name is not available on this system. >> PING ::1: (::1): 56 data bytes >> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms >> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms >> >> --- ::1 ping statistics --- >> 2 packets transmitted, 2 packets received, 0% packet loss >> round-trip min/avg/max = 0/0/0 ms >> PING ::1: (::1): 56 data bytes >> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms >> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms >> >> --- ::1 ping statistics --- >> 2 packets transmitted, 2 packets received, 0% packet loss >> >> >> A long commit message. >> >> This came to light because some systems failed with IPv4 (those that passed >> replaced 0.0.0.0 with the default router. but most just fail - not substituting >> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 >> which compares well with other platform's behavior. > > Michael Felt has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8280498: skip test because: AIX does not respond internally to 0.0.0.0; ::0 is invalid test/jdk/java/net/Inet4Address/PingThis.java line 37: > 35: * @bug 8280498 > 36: * @summary InetAddress ::0 is not valid, InetAddress 0.0.0.0 only responds > 37: * when an external device reacts to 0.0.0.0 I think this means the test has two @summary tags, did you mean to add a second? ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From dfuchs at openjdk.java.net Mon Feb 28 10:28:51 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 28 Feb 2022 10:28:51 GMT Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on AIX [v2] In-Reply-To: <0HCJI6idObe2Kkfy13TOuKJx5ueMNKDIx-cv6CErV_E=.d2a4a2a1-b717-4dd1-8e8f-abfddcafefdc@github.com> References: <0HCJI6idObe2Kkfy13TOuKJx5ueMNKDIx-cv6CErV_E=.d2a4a2a1-b717-4dd1-8e8f-abfddcafefdc@github.com> Message-ID: On Sun, 27 Feb 2022 14:07:57 GMT, Michael Felt wrote: >> Michael Felt has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. > > Force pushed - too many typos - so 'erased' the mess-ups @aixtools Thanks for the detailed analysis. It confirms the best course of action is to skip this test on AIX. Since changes will be to the test file only there's no need to list 8280498 in the test's `@bug` list - adding the `noreg-self` keyword to JDK-8280498 would be enough (I can do that). ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From dfuchs at openjdk.java.net Mon Feb 28 10:28:53 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 28 Feb 2022 10:28:53 GMT Subject: RFR: JDK-8280498: jdk/java/net/Inet4Address/PingThis.java fails on AIX [v3] In-Reply-To: References: Message-ID: <0Ud8F20bB-CI5mDvjqjSLsLRprkmx-eFnxWty0KcPYQ=.8b96b615-9b70-4464-ac80-7150507bab22@github.com> On Sun, 27 Feb 2022 14:11:28 GMT, Michael Felt wrote: >> with IP "0.0.0.0" >> >> - it either does nothing and ping fails, or, in some virtual environments >> is treated as the default route address. >> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted >> as a vaild psuedo IPv6 address. '::1' must be used instead. >> >> ping: bind: The socket name is not available on this system. >> ping: bind: The socket name is not available on this system. >> PING ::1: (::1): 56 data bytes >> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.037 ms >> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.045 ms >> >> --- ::1 ping statistics --- >> 2 packets transmitted, 2 packets received, 0% packet loss >> round-trip min/avg/max = 0/0/0 ms >> PING ::1: (::1): 56 data bytes >> 64 bytes from ::1: icmp_seq=0 ttl=255 time=0.052 ms >> 64 bytes from ::1: icmp_seq=1 ttl=255 time=0.047 ms >> >> --- ::1 ping statistics --- >> 2 packets transmitted, 2 packets received, 0% packet loss >> >> >> A long commit message. >> >> This came to light because some systems failed with IPv4 (those that passed >> replaced 0.0.0.0 with the default router. but most just fail - not substituting >> 0.0.0.0 with 127.0.0.1. However, InetAddress.getByName("") returns 127.0.0.1 >> which compares well with other platform's behavior. > > Michael Felt has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8280498: skip test because: AIX does not respond internally to 0.0.0.0; ::0 is invalid test/jdk/java/net/Inet4Address/PingThis.java line 37: > 35: * @bug 8280498 > 36: * @summary InetAddress ::0 is not valid, InetAddress 0.0.0.0 only responds > 37: * when an external device reacts to 0.0.0.0 Maybe that information could be added as a comment just before `return;` on line 52 instead: `// On AIX, ...` ------------- PR: https://git.openjdk.java.net/jdk/pull/7013 From jpai at openjdk.java.net Mon Feb 28 12:48:41 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 28 Feb 2022 12:48:41 GMT Subject: RFR: 8209137: Add ability to bind to specific local address to HTTP client [v13] In-Reply-To: References: Message-ID: > 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 27 additional commits since the last revision: - 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 - By default add SocketPermission for java.net.http module to allow binding to non-ephemeral ports if local bind address is configured for HTTPClient - ... and 17 more: https://git.openjdk.java.net/jdk/compare/1e84652c...e163f13c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6690/files - new: https://git.openjdk.java.net/jdk/pull/6690/files/73010886..e163f13c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6690&range=11-12 Stats: 10445 lines in 242 files changed: 7851 ins; 751 del; 1843 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 jnimeh at openjdk.java.net Mon Feb 28 19:47:35 2022 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Mon, 28 Feb 2022 19:47:35 GMT Subject: RFR: 8273042: TLS Certificate Compression In-Reply-To: References: Message-ID: <8aulg1Sv0Lu9Yv0MznJceizD4krTUHmIHLyzrYKK-8Q=.16c8990e-230a-4b7c-8372-57fe1d5955a2@github.com> On Wed, 23 Feb 2022 20:15:24 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > Please review the implementation of RFC 8879, TLS Certificate Compression, in JDK. The TLS Certificate Compression standard is an essential part for QUIC connections and performance improvement for TLS connections. More details, please refer to the [JEP](https://bugs.openjdk.java.net/browse/JDK-8281710) proposal. > > The JEP was submitted, and it may take time for the final approval. But let me know you ideas and concerns about the proposal and implementation. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8281710 src/java.base/share/classes/sun/security/ssl/CompressionAlgorithm.java line 49: > 47: } > 48: > 49: static CompressionAlgorithm nameOf(String name) { Shouldn't this be valueOf? We're not consistent in the method name across all our sun.security.ssl enumerations, but more often than not when we return the enumeration object it's via a valueOf call. ------------- PR: https://git.openjdk.java.net/jdk/pull/7599 From jnimeh at openjdk.java.net Mon Feb 28 19:47:35 2022 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Mon, 28 Feb 2022 19:47:35 GMT Subject: RFR: 8273042: TLS Certificate Compression In-Reply-To: <8aulg1Sv0Lu9Yv0MznJceizD4krTUHmIHLyzrYKK-8Q=.16c8990e-230a-4b7c-8372-57fe1d5955a2@github.com> References: <8aulg1Sv0Lu9Yv0MznJceizD4krTUHmIHLyzrYKK-8Q=.16c8990e-230a-4b7c-8372-57fe1d5955a2@github.com> Message-ID: On Mon, 28 Feb 2022 19:41:59 GMT, Jamil Nimeh wrote: >> Hi, >> >> Please review the implementation of RFC 8879, TLS Certificate Compression, in JDK. The TLS Certificate Compression standard is an essential part for QUIC connections and performance improvement for TLS connections. More details, please refer to the [JEP](https://bugs.openjdk.java.net/browse/JDK-8281710) proposal. >> >> The JEP was submitted, and it may take time for the final approval. But let me know you ideas and concerns about the proposal and implementation. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8281710 > > src/java.base/share/classes/sun/security/ssl/CompressionAlgorithm.java line 49: > >> 47: } >> 48: >> 49: static CompressionAlgorithm nameOf(String name) { > > Shouldn't this be valueOf? We're not consistent in the method name across all our sun.security.ssl enumerations, but more often than not when we return the enumeration object it's via a valueOf call. Hmmm...I take that back. Seems like when the input is a string we do go by nameOf. Maybe this is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/7599 From xuelei at openjdk.java.net Mon Feb 28 23:12:27 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 28 Feb 2022 23:12:27 GMT Subject: RFR: 8273042: TLS Certificate Compression In-Reply-To: References: <8aulg1Sv0Lu9Yv0MznJceizD4krTUHmIHLyzrYKK-8Q=.16c8990e-230a-4b7c-8372-57fe1d5955a2@github.com> Message-ID: On Mon, 28 Feb 2022 19:44:19 GMT, Jamil Nimeh wrote: >> src/java.base/share/classes/sun/security/ssl/CompressionAlgorithm.java line 49: >> >>> 47: } >>> 48: >>> 49: static CompressionAlgorithm nameOf(String name) { >> >> Shouldn't this be valueOf? We're not consistent in the method name across all our sun.security.ssl enumerations, but more often than not when we return the enumeration object it's via a valueOf call. > > Hmmm...I take that back. Seems like when the input is a string we do go by nameOf. Maybe this is fine. I think I see your points. valueOf(String) is a built-in method of enum, where the String input is not the one was expected for the nameOf(String) method. So nameOf() was used a lot in the SunJSSE provider implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7599