IPV6 literal string handling in tests
Hello net-dev
I have been investigating an intermittent error with the following tests in
jdk11u and
identified fixes that could be back-ported:
tests/jdk/sun/net/www/protocal/httponly.java
tests/jdk/sun/net/www/protocal/nocache.java
The error was a malformed string being passed to the URI/URL constructor
(that parses the given string) in the format "http://0:0:0:0:1%1:65500/path";,
the root cause being that InetAddress.getHostAddress in some cases returns
an IPV6 literal string (e.g. "0:0:0:0:1%1"), this specific constructor
expects IPV6 literals to be enclosed in brackets e.g.
"http://[0:0:0:0:1%1]:65500/path
The issue has been addressed in tip with following change
https://hg.openjdk.java.net/jdk/jdk/rev/5302477c8285 in response
to https://bugs.openjdk.java.net/browse/JDK-8224761
Has there been discussion about back-porting the fix to the tests to jdk11u?
I looked for other tests with the pattern that can result in malformed URLs
and only found one case in:
tests/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
This has also been fixed in tip with a different change
http://hg.openjdk.java.net/jdk/jdk/rev/3131927311ee
in response to https://bugs.openjdk.java.net/browse/JDK-8230858
However these two changes achieve the same results using two different
solutions;
the fix for B5045306.java and 12 other tests in tip use the following code
pattern when
using the URI/URL constructor that takes a string to parse:
String hostAddr = InetAddress.getLocalHost().getHostAddress();
if (hostAddr.indexof(':') > -1) hostAddr = "[" + hostAddr + "]";
Whereas the fix for httponly.java and nocache.java use the test utility class
test/lib/jdk/tests/lib/net/URIBuilder.java, which essentially boils down to
using
the URI/URL constructor that constructs a hierarchical URI from the given
components
Regardless of whether the fixes are back-ported to jdk11u, is there a shared
view in
this mailing list that we pick one pattern on tip for consistency, I'm happy to
make
the changes if there is agreement
Thanks in advance
Mat Carter
Microsoft
Re: RFR(s): Improving performance of Windows socket connect on the loopback adapter
Nikola has opened an issue to cover the loopback address range and we're
preparing a patch:
https://bugs.openjdk.java.net/browse/JDK-8255264
We've identified some unit tests to include in the patch, does
gtest/runtime/test_os_windows.cpp seem the appropriate location for them?
Patch (preview):
diff --git a/src/java.base/windows/native/libnet/net_util_md.h
b/src/java.base/windows/native/libnet/net_util_md.h
index b76935db3de..2f873b6295e 100644
--- a/src/java.base/windows/native/libnet/net_util_md.h
+++ b/src/java.base/windows/native/libnet/net_util_md.h
@@ -90,24 +90,30 @@ struct ipv6bind {
/**
* With dual socket implementation the
* IPv4 addresseses might be mapped as IPv6.
- * The IPv4 loopback adapter address will
- * be mapped as the following IPv6 :::127.0.0.1.
+ * The IPv4 loopback adapter address ranges (127.0.0.0 through
127.255.255.255) will
+ * be mapped as the following IPv6 :::127.0.0.0 through
:::127.255.255.255.
* For example, this is done by NET_InetAddressToSockaddr.
*/
#define IN6_IS_ADDR_V4MAPPED_LOOPBACK(x) ( \
-(((x)->s6_words[0] == 0) && \
- ((x)->s6_words[1] == 0) && \
- ((x)->s6_words[2] == 0) && \
- ((x)->s6_words[3] == 0) && \
- ((x)->s6_words[4] == 0) && \
- ((x)->s6_words[5] == 0x) && \
- ((x)->s6_words[6] == 0x007F) && \
- ((x)->s6_words[7] == 0x0100))\
+(((x)->s6_words[0] == 0) && \
+ ((x)->s6_words[1] == 0) && \
+ ((x)->s6_words[2] == 0) && \
+ ((x)->s6_words[3] == 0) && \
+ ((x)->s6_words[4] == 0) && \
+ ((x)->s6_words[5] == 0x) && \
+ (((x)->s6_words[6] & 0x00FF) == 0x007F)) \
+)
+
+/**
+ * Check for IPv4 loopback adapter address ranges (127.0.0.0 through
127.255.255.255)
+ */
+#define IN4_IS_ADDR_NETLONG_LOOPBACK(l) ( \
+((l & 0xFF00) == 0x7F00) \
)
#define IS_LOOPBACK_ADDRESS(x) ( \
((x)->sa.sa_family == AF_INET) ? \
-(ntohl((x)->sa4.sin_addr.s_addr) == INADDR_LOOPBACK) : \
+(IN4_IS_ADDR_NETLONG_LOOPBACK(ntohl((x)->sa4.sin_addr.s_addr))) : \
((IN6_IS_ADDR_LOOPBACK(&(x)->sa6.sin6_addr)) || \
(IN6_IS_ADDR_V4MAPPED_LOOPBACK(&(x)->sa6.sin6_addr))) \
)
Cheers
Mat
From: net-dev on behalf of Nikola Grcevski
Sent: Thursday, August 6, 2020 7:37 AM
To: Alan Bateman ; net-dev@openjdk.java.net
Subject: RE: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
Yes, please.
Thank you,
Nikola
-Original Message-
From: Alan Bateman
Sent: August 6, 2020 9:49 AM
To: Nikola Grcevski ; net-dev@openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
On 04/08/2020 16:36, Nikola Grcevski wrote:
> Hi Alan,
>
>> What cheap is VerifyVersionInfoW? The check is done everytime but the
>> overhead might be in the noise. Overall it looks good to me.
> I wrote a small benchmark to measure the overhead of the version check
> (attached below).
>
> On my SurfaceBook 2 running Windows 10 Build 19041, the version check
> measures about ~2.2us (micro seconds) on average, when the version matches.
>
> Elapsed time 2244us. (for 1,000 iterations)
>
> On a Windows 2016 Data Center Server the version check is much smaller
> ~0.13us (micro seconds) on average, when the version doesn't match.
>
> Elapsed time 128us. (for 1,000 iterations)
>
> I think the overhead is reasonably small compared to everything else. Please
> let me know if it's acceptable and if we can proceed.
>
>
Okay. So do you me to sponsor this?
-Alan
RFR: 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows
Modified Windows specific loopback macros to support full range of loopback addresses, commit message includes unit test data as there's no gtest's for java libraries (only hotspot compiler) This is an expansion on the original fix for 8250521: Configure initial RTO to use minimal retry for loopback connections on Windows IPV4 loopback addresses are defined as 127.0.0.0/8 the CIDR translates to a range of 127.0.0.0 to 127.255.255.255 inclusive. The previous macro implementation only identified 127.0.0.1 and ::1 as loopback addresses, this is corrected in this change Note that as IPV6 is defined as ::1/128 only ::1 is a valid loopback address - Commit messages: - 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows Changes: https://git.openjdk.java.net/jdk/pull/1523/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1523&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255264 Stats: 17 lines in 1 file changed: 6 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1523.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1523/head:pull/1523 PR: https://git.openjdk.java.net/jdk/pull/1523
Re: RFR: 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows
Have an RFR needing a sponsor and review - this is related to Nikola's prior work on JDK-8250521: Configure initial RTO to use minimal retry for loopback connections on Windows Thanks in advance Mat Carter Sent from Outlook From: net-dev on behalf of Mat Carter Sent: Tuesday, December 1, 2020 8:45 AM To: net-dev@openjdk.java.net Subject: RFR: 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows Modified Windows specific loopback macros to support full range of loopback addresses, commit message includes unit test data as there's no gtest's for java libraries (only hotspot compiler) This is an expansion on the original fix for 8250521: Configure initial RTO to use minimal retry for loopback connections on Windows IPV4 loopback addresses are defined as 127.0.0.0/8 the CIDR translates to a range of 127.0.0.0 to 127.255.255.255 inclusive. The previous macro implementation only identified 127.0.0.1 and ::1 as loopback addresses, this is corrected in this change Note that as IPV6 is defined as ::1/128 only ::1 is a valid loopback address - Commit messages: - 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows Changes: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.java.net%2Fjdk%2Fpull%2F1523%2Ffiles&data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=E6vGW2cv%2F8xbbwQ7LXAHnNJlCMz%2FDYuE2mf7Cb4XL%2F8%3D&reserved=0 Webrev: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebrevs.openjdk.java.net%2F%3Frepo%3Djdk%26pr%3D1523%26range%3D00&data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3zrfHSmoebfb6frkKY2hiPvFmE2fwfWD0JTSKP0GySU%3D&reserved=0 Issue: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8255264&data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nARpDuRflecA48G4BuWoDTXLE1eq9oM%2BExoEnnaPfEM%3D&reserved=0 Stats: 17 lines in 1 file changed: 6 ins; 0 del; 11 mod Patch: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.java.net%2Fjdk%2Fpull%2F1523.diff&data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Sij9ITYHDondJDDG2SGfxMCuu84rDAncUWPiKQP3YdY%3D&reserved=0 Fetch: git fetch https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.java.net%2Fjdk&data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EL%2BrIjy0g%2FQtORAa2bSNQQvJJ%2Fv9vB%2FJjReuUy5e798%3D&reserved=0 pull/1523/head:pull/1523 PR: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.java.net%2Fjdk%2Fpull%2F1523&data=04%7C01%7Cmatthew.carter%40microsoft.com%7C064ac0511f8d456a8f0108d89618859e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637424379353506711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tDt7IKZIie43WPEiWvVEiqoGBvIg6erjxbqLw%2BqUzAg%3D&reserved=0
Re: RFR: 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows
On Wed, 23 Dec 2020 16:10:27 GMT, Alan Bateman wrote: >> Modified Windows specific loopback macros to support full range of loopback >> addresses, commit message includes unit test data as there's no gtest's for >> java libraries (only hotspot compiler) >> >> This is an expansion on the original fix for 8250521: Configure initial RTO >> to use minimal retry for loopback connections on Windows >> >> IPV4 loopback addresses are defined as 127.0.0.0/8 the CIDR translates to a >> range of 127.0.0.0 to >> 127.255.255.255 inclusive. >> >> The previous macro implementation only identified 127.0.0.1 and ::1 as >> loopback addresses, this is corrected in this change >> >> Note that as IPV6 is defined as ::1/128 only ::1 is a valid loopback address > > Looks good. Thanks for the review Alan - PR: https://git.openjdk.java.net/jdk/pull/1523
Integrated: 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows
On Mon, 30 Nov 2020 18:09:57 GMT, Mat Carter wrote: > Modified Windows specific loopback macros to support full range of loopback > addresses, commit message includes unit test data as there's no gtest's for > java libraries (only hotspot compiler) > > This is an expansion on the original fix for 8250521: Configure initial RTO > to use minimal retry for loopback connections on Windows > > IPV4 loopback addresses are defined as 127.0.0.0/8 the CIDR translates to a > range of 127.0.0.0 to > 127.255.255.255 inclusive. > > The previous macro implementation only identified 127.0.0.1 and ::1 as > loopback addresses, this is corrected in this change > > Note that as IPV6 is defined as ::1/128 only ::1 is a valid loopback address This pull request has now been integrated. Changeset: 7e01bc96 Author:Mat Carter Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/7e01bc96 Stats: 17 lines in 1 file changed: 6 ins; 0 del; 11 mod 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/1523
