[7u8] [Re: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException (original) (raw)

Joe Wang huizhe.wang at oracle.com
Tue Jul 10 21:01:44 UTC 2012

Hi Paul,

I agree, it looked quite messy, isn't it :), keeping a hack that generates encoded url and yet not support IPv6 addresses that contain international characters?

It IS a more preferable solution to remove the hack of using escapeNonUSAscii -- so I'll do :)

Thanks, Joe

On 7/10/2012 12:26 PM, Paul Sandoz wrote:

Hi Joe,

If you are gonna fix things to support IPv6 addresses in URLs i really think you need to make it work for URLs with international characters too. On Jul 10, 2012, at 8:50 PM, Joe Wang wrote:

602 if (reader == null) { 603 stream = xmlInputSource.getByteStream(); 604 if (stream == null) { 605 URL location = new URL(escapeNonUSAscii(expandedSystemId)); 606 URLConnection connect = location.openConnection(); 607 if (!(connect instanceof HttpURLConnection)) { 608 stream = connect.getInputStream(); 609 }

If this is really about supporting non-percent encoded international characters in the system ID, then you can make a simple fix to support IPv6-based URLs in general: do not percent encoded any ascii characters. When encoding an url, aren't reserved characters supposed to be encoded as well? Your fix does not do that: 2608 protected static String escapeNonUSAscii(String str) { 2609 if (str == null) { 2610 return str; 2611 } 2612 int len = str.length(), i=0, ch; 2613 for (; i< len; i++) {_ _2614 ch = str.charAt(i);_ _2615 // if it's not an ASCII 7 character, break here, and use UTF-8 encoding_ _2616 if (ch>= 128) 2617 break; 2618 } 2619 2620 // we saw no non-ascii-7 character 2621 if (i == len) { 2622 return str; //<--- reserved characters are not percent-encoded 2623 } 2624 I know it is deliberate attempt to avoid '[' and ']' characters being percent encoded, whether the URL has an IPv6 address or not, even though '[' and ']' are reserved characters outside of an IPv6 address . My point is if you don't encode reserved ASCII characters when all the characters in the URL are ASCII characters then don't encode reserved ASCII characters when there are also international characters present that will be encoded. Then "escapeNonUSAscii" actually does what the method is called :-) Otherwise the other, more preferable solution IMHO, is to remove the hack of using escapeNonUSAscii. Paul.

More information about the core-libs-dev mailing list