Re: RFR: 8275534: com.sun.net.httpserver.BasicAuthenticator should check whether "realm" is a quoted string
On Tue, 26 Oct 2021 12:46:31 GMT, Julia Boes wrote:
> This change ensures that the realm string passed to the BasicAuthenticator
> constructor is a quoted-string, as per RFC7230 [1]. A Utils class is added to
> jdk.httpserver/sun.net.httpserver that holds the new isQuotedString() method
> and the pre-existing isValidName() method (previously in ServerImpl.)
> Two tests are included:
> - BasicAuthenticatorRealm.java to check that Latin-1 chars in the realm
> string are transported correctly,
> - BasicAuthenticatorExceptionCheck.java to check realm strings with escaped
> quotes.
>
> Testing: tier 1-3.
>
> [1] https://datatracker.ietf.org/doc/html/rfc7230
Changes requested by michaelm (Reviewer).
src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java
line 56:
> 54: * realm string, it must be escaped by two preceding backslashes, for
> example
> 55: * {@code "foo\\\"bar\\\""} will be embedded as {@code "foo\"bar\""}.
> 56: *
I'm not sure the point really warrants an API note like this. I think the
specification is clear enough from the @throws clause.
src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java
line 77:
> 75: * Where a backslash ("\") is used as quoting mechanism within the
> realm
> 76: * string, it must be escaped by two preceding backslashes, for
> example
> 77: * {@code "foo\\\"bar\\\""} will be embedded as {@code "foo\"bar\""}.
Same point as above
-
PR: https://git.openjdk.java.net/jdk/pull/6117
Re: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments
On Sat, 23 Oct 2021 10:26:34 GMT, Daniel Jeliński wrote: > Clean up of various issues related to error handling and memory management Hi Daniel - it looks like your changeset is reverting all the changes that were made by [JDK-8046500](https://bugs.openjdk.java.net/browse/JDK-8046500), to fix an issue where no interfaces were returned on machines that had only IPv6 interfaces (and no IPv4). See https://mail.openjdk.java.net/pipermail/net-dev/2018-November/011931.html ; Were you able to test that `NetworkInterface.getNetworkInterfaces()` will not fail on a machine where IPv4 has been disabled with `netsh interface ipv4 uninstall` ? - PR: https://git.openjdk.java.net/jdk/pull/6090
Re: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only environments
On Sat, 23 Oct 2021 10:26:34 GMT, Daniel Jeliński wrote: > Clean up of various issues related to error handling and memory management Hi, I wasn't able to run the test yet; need to find a machine where I could run this test without worrying about restoring it to a working state. However, looking at the code, I think it's broken already. JDK-8046500 says GetIpAddrTable fails on IPv6-only machines. This method is only called in `lookupIPAddrTable`, and `getAllInterfacesAndAddresses` ignores -2 result since 7f1f9a50ae87e745e552ed8a3b7028cd49638441. Still, `enumAddresses_win` probably needs more love. I'll look into it. - PR: https://git.openjdk.java.net/jdk/pull/6090
Re: RFR: JDK-8275518: accessibility issue in Inet6Address docs
On Tue, 19 Oct 2021 13:50:20 GMT, Ludvig Janiuk wrote: > Single-row table was being used for visual effect, but a description list > seems more appropriate. OK, but ... While the basic translation from a single-row table to a definition list looks good, it's not clear you still need the `style` attribute. Also, explicit use of `` and `` is discouraged for accessibility reasons; if you need any tags to adjust the font here, it's better to use semantic equivalents like `` and `` (emphasis). But even better to reduce unnecessary stylistic changes and rely on the default settings (in this case for ``) in the stylesheet. - Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6010
Integrated: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes
On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. There are more modern > alternatives which perform better: > 1. Plain String concatenation should be preferred > 2. StringBuilder is a direct replacement to StringBuffer which generally have > better performance > > In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) I > migrated only usages which were automatically detected by IDEA. It turns out > there are more usages which can be migrated. This pull request has now been integrated. Changeset: 9a3e9542 Author:Andrey Turbanov Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/9a3e9542997860de79d07a4411b1007e9cd5c348 Stats: 31 lines in 11 files changed: 0 ins; 0 del; 31 mod 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes Reviewed-by: naoto - PR: https://git.openjdk.java.net/jdk/pull/5432
Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v9]
On Tue, 26 Oct 2021 16:24:48 GMT, Aleksei Efimov wrote:
>> This change implements a new service provider interface for host name and
>> address resolution, so that java.net.InetAddress API can make use of
>> resolvers other than the platform's built-in resolver.
>>
>> The following API classes are added to `java.net.spi` package to facilitate
>> this:
>> - `InetAddressResolverProvider` - abstract class defining a service, and
>> is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the
>> platform's built-in configuration for resolution operations that could be
>> used to bootstrap a resolver construction, or to implement partial
>> delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the
>> fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the
>> characteristics of one forward lookup operation.
>>
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>>
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add @ throws NPE to hosts file resolver javadoc
src/java.base/share/classes/java/net/InetAddress.java line 841:
> 839: // 'resolver.lookupByAddress' and 'InetAddress.getAllByName0'
> delegate to the system-wide resolver,
> 840: // which could be a custom one. At that point we treat any
> unexpected RuntimeException thrown by
> 841: // the resolver as we would treat an UnknownHostException or an
> unmatched host name.
indentation issue in comment above
src/java.base/share/classes/java/net/InetAddress.java line 1308:
> 1306: * Creates an InetAddress based on the provided host name and IP
> address.
> 1307: * System {@linkplain InetAddressResolver resolver} is not used to
> check
> 1308: * the validity of the address.
Is this term "system resolver" defined somewhere? I think it means the
configured resolver for the current VM. Previously, it really was the system
resolver. So, I think it's potentially confusing, as there is also reference to
the java.net.preferIPv6Addresses system property as having a possible value
"system" which refers to the operating system. Since the CSR is approved, I'm
happy to discuss this point post integration.
-
PR: https://git.openjdk.java.net/jdk/pull/5822
