JDK-8072064 : toLowerCase() in java.net.HostPortrange fails on underscore character
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 8u25,9,9.0.1,10
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2014-12-22
  • Updated: 2020-12-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

EXTRA RELEVANT SYSTEM CONFIGURATION :
should not matter

A DESCRIPTION OF THE PROBLEM :
In NetBeans 8.0.2 running on JDK 1.8.0_25 I was adding a Web Service Client. I inserted WSDL address, but the environment constantly returned "Problem with downloading wsdl or schema file", although it worked in other applications.
After thorough investigation I have found that the problem is that the address contained underscores and the error is invoked by the IllegalArgumentException("Invalid characters in hostname") that was thrown by toLoweCase() method in java.net.HostPortrange.
This method checks the characters of an address and if they are not within [a-z0-9A-Z.-] an exception is thrown even though also other characters are valid in URL.

ADDITIONAL REGRESSION INFORMATION: 
The same problem was in 1.8.0_11 and 1.8.0_05. The problem was not in 1.7.0_65.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
In NetBeans running on 1.8.0_xx create a new project and add a Web Service Client and as a WSDL URL use a URL containing underscores. After clicking Finish, an error message appears. In View/IDE Log then could be seen:

INFO [org.netbeans.modules.websvc.core.client.wizard.ClientInfo]: "Unable to check if wsdl is rpc encoded."
java.lang.IllegalArgumentException: Invalid characters in hostname
	at java.net.HostPortrange.toLowerCase(HostPortrange.java:189)
	at java.net.HostPortrange.<init>(HostPortrange.java:150)
	at java.net.URLPermission$Authority.<init>(URLPermission.java:481)
	at java.net.URLPermission.parseURI(URLPermission.java:449)
	at java.net.URLPermission.init(URLPermission.java:170)
	at java.net.URLPermission.<init>(URLPermission.java:166)


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected result is no exception and WSDL normally added.
ACTUAL -
The request fails with an error described above.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
INFO [org.netbeans.modules.websvc.core.client.wizard.ClientInfo]: "Unable to check if wsdl is rpc encoded."
java.lang.IllegalArgumentException: Invalid characters in hostname
	at java.net.HostPortrange.toLowerCase(HostPortrange.java:189)
	at java.net.HostPortrange.<init>(HostPortrange.java:150)
	at java.net.URLPermission$Authority.<init>(URLPermission.java:481)
	at java.net.URLPermission.parseURI(URLPermission.java:449)
	at java.net.URLPermission.init(URLPermission.java:170)
	at java.net.URLPermission.<init>(URLPermission.java:166)
	at sun.net.www.protocol.http.HttpURLConnection.URLtoSocketPermission(HttpURLConnection.java:1031)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:981)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Using java 1.7 or working with code where WSDL was already imported.

SUPPORT :
YES


Comments
There's the same issue happened on win10-x64 with jre10.0.2b04-64bit-IE11 RULE "JWSSecurityWarningDialogs/testCheckLocationLongDomain" any any There's the same issue happened on win10-x64 with jre10.0.2b05-64bit-IE11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any There's the same issue happened on mac10.13-x64 with jre10.0.2b07-64bit-safari11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any There's the same issue happened on mac10.13-x64 with jre10.0.2b10-64bit-safari11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
21-06-2018

There's the same issue happened on win7-x64 with jre10b37-64bit-Chrome RULE "JWSSecurityWarningDialogs/testCheckLocationLongDomain" any any There's the same issue happened on ubuntu17.04-x64 with jre10b37-64bit-FF-ESR52.5.2 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any There's the same issue happened on mac10.13-x64 with jre10b37-64bit-FF-ESR52.5.2 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any There's the same issue happened on mac10.11-x64 with jre10.0.1b01-64bit-safari9 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any There's the same issue happened on mac10.13-x64 with jre10b40-64bit-safari11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any There's the same issue happened on mac10.12-x64 with jre10b41-64bit-FF-ESR52.6 There's the same issue happened on ubuntu17.04-x64 with jre10b41-64bit-FF_ESR52.6 RULE "JWSSecurityWarningDialogs/testCheckLocationLongDomain" any any There's the same issue happened on win10-x64-jre10b41-64bit-IE11 RULE "JWSSecurityWarningDialogs/testCheckLocationLongDomain" any any There's the same issue happened on win10-x64 with jre10.0.1b03-64bit-IE11 RULE "JWSSecurityWarningDialogs/testCheckLocationLongDomain" any any There's the same issue happened on mac10.13-x64 with jre10.0.1b04-64bit-safari11 RULE "JWSSecurityWarningDialogs/testCheckLocationLongDomain" any any There's the same issue happened on ubuntu16.04-x64 with jre10.0.1b04-64bit-FF-ESR52.6.0 RULE "JWSSecurityWarningDialogs/testCheckLocationLongDomain" any any There's the same issue happened on mac10.13-x64 with jre10.0.1b06-64bit-safari11 RULE "JWSSecurityWarningDialogs/testCheckLocationLongDomain" any any
24-02-2018

There's the same issue happened on win10-x64 with jre9.0.4b03-64bit-IE11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any There's the same issue happened on mac10.11-x64 with jre9.0.4b05-64bit-Safari9 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any There's the same issue happened on ubuntu16.04-x64 with jre9.0.4b6-64bit RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
17-11-2017

There's the same issue happened on ubuntu16.04-x64-jre9.0.3b05-64bit-FF51 There's the same issue happened on mac10.12-x64 with jre9.0.3b06-64bit-safari10 There's the same issue happened on win8.1-x64 with jre9.0.3b06-64bit-IE11 There's the same issue happened on win8.1-x86 with jre9.0.3b09-32bit-IE11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
11-09-2017

The changes can be made in HostPortrange parsing to mitigate the issue, But it would be prudent to address the issue more completely and explore the alignment and interpretation of the parsing algorithm to align with relevant RFCs for URL and URIs https://tools.ietf.org/html/rfc3986 It may be reasonable to align the HostPortrange with URI authority host definition BNF extracts from RFC3986: authority = [ userinfo "@" ] host [ ":" port ] userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) host = IP-literal / IPv4address / reg-name port = *DIGIT reg-name = *( unreserved / pct-encoded / sub-delims ) pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" while the current interpretation for HostPortrange is aligned with RFC 2396, and as such the hostname part of the authority cannot have underscore in it, as per the BNF in appendix A c.f. https://tools.ietf.org/html/rfc2396#appendix-A extract from 2396: server = [ [ userinfo "@" ] hostport ] userinfo = *( unreserved | escaped | ";" | ":" | "&" | "=" | "+" | "$" | "," ) hostport = host [ ":" port ] host = hostname | IPv4address hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum toplabel = alpha | alpha *( alphanum | "-" ) alphanum IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit port = *digit
24-08-2017

There's the same issue happened on win10-x64 with jre9.0.3b05-32bit-IE11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
15-08-2017

There's the same issue happened on mac10.12-x64 with jre9b177-64bit/Safari10 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
10-07-2017

There's the same issue happened on win10-x64 with jre9b177-64bit-IE11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
07-07-2017

There's the same issue happened on mac10.12-x64 with jre9b176-64bit/Safari10 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
03-07-2017

Hey, folks - I'm subscribed to this bug for genuine updates. I don't think there is any question that this is an issue in the JDK. Is there some internal reason that it needs to be pinged several times a week saying that it is still an issue?
30-06-2017

There's the same issue happened on win10-x64 with jre9b176-64bit-IE11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
30-06-2017

There's the same issue happened on mac10.11-x64 with jre9b175-64bit-Safari9 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
23-06-2017

There's the same issue happened on win10-x64 with jre9b175-64bit-IE11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
23-06-2017

There's the same issue happened on ubuntu16.04-x86 with jre9b175-32bit RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
22-06-2017

There's the same issue happened on ubuntu16.10-x64-jre9b174-64bit
22-06-2017

There's the same issue happened on mac10.12-x64 with jre9b174-64bit/safari10
16-06-2017

There's the same issue happened on win7-x86 with jre9b174-32bit-IE11
15-06-2017

There's the same issue happened on mac10.11-64bit with jre9b173-64bit-Safari9
14-06-2017

There's the same issue happened on ubuntu16.04-x86 with jre9b173-32bit
12-06-2017

There's the same issue happened on win10-x64 with jre9b173-64bit-IE11
08-06-2017

There's the same issue happened on mac10.12-x64-jre9b172-64bit-Safari10
06-06-2017

There's the same issue happened on win7-x86 with jre9b172-32bit-IE11
02-06-2017

There's the same issue happened on ubuntu16.10-x64 with jre9b172-64bit-FF51.0
02-06-2017

There's the same issue happened on ubuntu16.04-x86 with jre9b171-32bit-FF50.0.1
01-06-2017

There's the same issue happened on win10-x64 with jre9b171-64bit-IE11
31-05-2017

There's the same issue happened on Mac10.11-x64-jre9b171-64bit-safari9
27-05-2017

There's the same issue happened on Mac10.12-x64-jre9b170-64bit-safari10
25-05-2017

There's the same issue happened on win7-x86-jre9b170-32bit-IE11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
25-05-2017

the HostPortrane::toLowerCase method that is invoked as part of the hostname parsing in the URLPermission, is RFC compliant for hostnames (as per rfc2822, rfc1035 etc and rfc2396), but it might be argued that it not aligned with the authority parsing of URLs/URIs as per rfc3986, c.f. the BNF for a host part of the authority below, but is for rfc2396 So for hostnames or fqdn then there is a contextual aspect to them. In the main FQDN or hostnames tend to be governed by RFCs such rfc2822, rfc1035 rfc 1123 rfc952 ... in these there is a general abstraction of a compound name made up of dot "." separated name components these name components are restricted to letters digit and hyphen. In the context of the authority part of a URI, which can contain a hostname, then there appears to be a divergence with the above rfc1035 based interpretation taking the example URL from 8159576 http://my_test_domain_for_domain_name_correct_truncate_testing_to_80nn.oracle.com:8080/JWSSecurityWarningDialogs/jnlp/testSelfSigned.jnlp this is accepted for both URL and URI and extracting the hostname part from the URL my_test_domain_for_domain_name_correct_truncate_testing_to_80nn.oracle.com will be accepted by InetAddress.getByName() in that no exceptions are thrown. It may be reasonable to align the HostPortrange with URI authority host definition BNF extracts from RFC3986: authority = [ userinfo "@" ] host [ ":" port ] userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) host = IP-literal / IPv4address / reg-name port = *DIGIT reg-name = *( unreserved / pct-encoded / sub-delims ) pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
25-05-2017

There's the same issue happened on ubuntu16.10-x64 with jre9b170-64bit-FF50.0 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
24-05-2017

There's the same issue happened on win10-x64 with jre9b167-64bit-IE11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
28-04-2017

There's the same issue happened on win10-x64 with jre9b166-64bit-IE11 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
24-04-2017

There's the same issue happened on mac10.12-x64 with jre9b155-64bit-safari10 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
07-02-2017

There's the same issue happened on ubuntu16.04-x86 with jre9b155-32bit-ff51.0.1 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
06-02-2017

There's the same issue happened on oel7.1-redhat-x64 with jre9b153-64bit-firefox50.1.0 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
20-01-2017

There's the same issue happened on mac10.12-x64 with jre9b151-64bit-safari10 RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
12-01-2017

[~tonyli] What is 'win7-x64-jre9b151-64bit-IE11', hostname, build, something else? How does it relate to this bug?
10-01-2017

There's the same issue happened on win7-x64-jre9b151-64bit-IE11
10-01-2017

There's the same issue happened on win 7-x86-jre9b150-32bit-IE11
04-01-2017

I believe that the host names in the comments above are somewhat misleading. It is my understanding that there is a local mapping on said machines from 127.0.0.1 to a hostname with at least one underscore ( '_' ) in it, and it is this that triggers the failure, not the "real" hostname ( that contains a dash ( '-' ) ). A quick search on the internet shows much confusion about the "allowability" of underscore in hostnames. Although most folk seem to accept that it is not strictly permitted, but appears to be, somewhat, widely used. I think URLPermission should be changed to allow underscore, as per the Robustness Principle [1]: "Be conservative in what you do, be liberal in what you accept from others" [1] https://en.wikipedia.org/wiki/Robustness_principle
03-01-2017

There's the same issue happened on win10-x64-jre9b150-64bit-IE11
28-12-2016

There's the same issue happened on Mac10.10-jre9b150-64bit-safari.
23-12-2016

There's the same issue happened on Mac10.11-x64-jre9b147-64bit
06-12-2016

There's the same issue happened onMac10.11-x64-jre9b147-64bit
06-12-2016

There's the same issue happened on win10-x64-jre9b147-64bit-IE11
02-12-2016

There's the same issue happened on win8.1-x86-jre9b146-32bit-IE11
25-11-2016

There's the same issue happened on ubuntu16.04-x86-jre9b146-32bit-FF50
25-11-2016

Hi Chris, You could refer to JDK-8159576
25-11-2016

There's the same issue happened on win8.1-x86 with jre9b135-32bit-IE11 effect case: RULE "JWSSecurityWarningDialogsScenarios/testCheckLocationLongDomain" any any
14-09-2016

[~tonyli] Can you please provide the URL strings that are being passed to URLPermission, that causes the exception. The hostnames that you site have a '-' ( dash ) in them, while this issue is specifically complaining about '_' ( underscore ).
13-09-2016

There's the same issue happened on win7-x86 with Jre9b134-32bit RULE "JWSSecurityWarningDialogs/testCheckLocationLongDomain" any any
02-09-2016

Affected Tests: RULE "JWSSecurityWarningDialogs/testCheckLocationLongDomain" any any
10-08-2016

This isn't jdk-8029354. That just fixes '@' characters. This is asking about the '_' character. The '_' character is technically illegal in hostnames, but it is very widely used. Is it worth considering fixing this?
24-07-2015

This is a duplicate of jdk-8029354 and confirms resolved fixed in latest JDK 8u40 ea and 9ea builds.
16-02-2015

Sent a reminder email to the submitter: ------------------------------------------------------------------------------- Hi Tomas, Can you check this with JDK 8u40 ea and JDK 9 ea versions. You can download them from: https://jdk8.java.net/download.html https://jdk9.java.net/download/ I have already tested this with the said versions and the issue seems resolved. Thank You, Pardeep --------------------------------------------------------------------------------
02-02-2015

This issue could be related to JDK-8029354 (fixed). Written back to the submitter to confirm with JDK 8u40 and JDK 9ea.
08-01-2015