Hi Mat,
On 16/07/2020 22:31, Mat Carter wrote:
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?
You would have to ask that on the jdk-updates-dev at openjdk.java.net
list. I personally would only ask to backport a test fix if the test
makes sufficient noise in the CI to justify the effort of
backporting it.
[...]
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 + "]";
Yes that's basically what the URIBuilder does under the hood,
by calling java.net.URI.
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
Usually I would recommend using URIBuilder. I might plead guilty for
not always using it consistently - and probably some of these places
could be updated to use it.
However there may be situations where using the simple two lines above
can make more sense: if for instance, the test is building up an URL
by concatenating strings that already contain some encoding - e.g.
the path or query have some %xx - or using an URI at that point
is impractical and would require restructuring the test (unlikely?).
best regards,
-- daniel
Thanks in advance
Mat Carter
Microsoft
