On Tue, 12 May 2026 19:00:41 GMT, Volkan Yazici <[email protected]> wrote:
>> Per [RFC 6066 "3. Server Name Indication"], disallow IP literals in >> `SNIHostName::new`. >> >> While the following two call-sites could be simplified by removing IP >> literal checks, I've refrained from doing so because delegating some of the >> checks to an exception catching mechanism would impact the performance: >> >> sun.security.ssl.Utilities::rawToSNIHostName >> sun.net.www.protocol.https.HttpsClient::afterConnect >> >> [RFC 6066 "3. Server Name Indication"]: >> https://www.rfc-editor.org/rfc/rfc6066.html#page-6 >> >> --------- >> - [X] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Volkan Yazici 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 19 additional > commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into sni > - Ensure `encoded` is copied > - Add tests and docs for UTF-8 vs. ASCII discrepancy > - Remove `{@return` tags > - Add reference to RFC 5280 > - Simplify "ASCII or UTF-8" with just "UTF-8" > - Revert javadoc changes from deprecated methods > - Do the forgotten update > - Improve wording and HTML rendering > - Merge remote-tracking branch 'upstream/master' into sni > - ... and 9 more: https://git.openjdk.org/jdk/compare/81b76567...0e562368 src/java.base/share/classes/javax/net/ssl/SNIHostName.java line 134: > 132: > 133: /** > 134: * Returns an {@code SNIHostName} using the specified hostname. Maybe "from" instead of "using' here. src/java.base/share/classes/javax/net/ssl/SNIHostName.java line 139: > 137: * href="http://www.ietf.org/rfc1123.txt";>RFC 1123</a> and <a > 138: * href="http://www.ietf.org/rfc5280.txt";>RFC 5280</a>), which > is > 139: * either an ASCII-encoded hostname or an {@linkplain IDN > Internationalized I think it would better to use the more restrictive "that is either" rather ", which is either" here. The repeated use of "hostname" could be dropped too to give you: "A valid SNI hostname is a DNS hostname (see RFC 1123 and RFC 5280) that is either ASCII-encoded or an Internationalized Domain Name (IDN)." src/java.base/share/classes/javax/net/ssl/SNIHostName.java line 173: > 171: * a decision depending on its context; e.g., propagate the failure, > or > 172: * report the issue and skip {@linkplain > SSLParameters#setServerNames(List) > 173: * the SNI server name configuration}. The wording in this API note is bit unusual. Is this API note needed? It is useful to suggest that the SNI server name configuration should be skipped? src/java.base/share/classes/javax/net/ssl/SNIHostName.java line 317: > 315: * either an ASCII-encoded hostname or an {@linkplain > 316: * IDN Internationalized Domain Name (IDN)}. A decoded hostname > string is > 317: * considered illegal if it: There's an error in "a valid a DNS". Maybe it would be clearer to split the long sentence, e.g. "This method decodes the bytes into a hostname string. The hostname is a DNS hostname ...". Can this method be specified to work the same as ofHostName if called with the decoded hostname? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30747#discussion_r3233340137 PR Review Comment: https://git.openjdk.org/jdk/pull/30747#discussion_r3233328700 PR Review Comment: https://git.openjdk.org/jdk/pull/30747#discussion_r3233411398 PR Review Comment: https://git.openjdk.org/jdk/pull/30747#discussion_r3233446697
