United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8023881 : IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII

Details
Type:
Bug
Submit Date:
2013-08-28
Status:
Closed
Updated Date:
2014-09-04
Project Name:
JDK
Resolved Date:
2013-08-30
Component:
core-libs
OS:
Sub-Component:
java.net
CPU:
Priority:
P2
Resolution:
Fixed
Affected Versions:
8
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Duplicate:
Relates:

Sub Tasks

Description
IDN.toASCII("??????.com", IDN.USE_STD3_ASCII_RULES) throws:

    Exception ... java.lang.IllegalArgumentException: Contains non-LDH characters
	at java.net.IDN.toASCIIInternal(IDN.java:275)
	at java.net.IDN.toASCII(IDN.java:118)


Per step 3, section 4.1, RFC 3490:

   3. If the UseSTD3ASCIIRules flag is set, then perform these checks:

     (a) Verify the absence of non-LDH ASCII code points; that is, the
         absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.

     (b) Verify the absence of leading and trailing hyphen-minus; that
         is, the absence of U+002D at the beginning and end of the
         sequence.

However, in the impl of IDN is checking far more strictly than above:

private static String toASCIIInternal(String label, int flag)
    ...
    if (useSTD3ASCIIRules) {
        for (int i = 0; i < dest.length(); i++) {
            int c = dest.charAt(i);
            if (!isLDHChar(c)) {
                throw new IllegalArgumentException(
                    "Contains non-LDH characters");
            }
        }
    ...
}

private static boolean isLDHChar(int ch){
    // high runner case
    if(ch > 0x007A){
        return false;
    }
    ...
}

isLDHChar() does not accept Unicode bigger than 0x007A. For example
"0x3041" ("???") is denied.  It is too strict to convert Unicode with IDN.toASCII().


I run a simple test with an Internationalized Domain Names command line
tool, idn, on linux:

$ idn --usestd3asciirules www.??????.com
www.xn--fsq092h.com

It means that Unicode is acceptable to IDN toASCII conversion (idn tool) even the
UseSTD3ASCIIRules is set.
                                    

Comments
I set this bug as P2 because it impacts the SNIHostName behavior a lot.  See also JDK-8019785.
                                     
2013-08-28
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdf68747b0fb
User:  xuelei
Date:  2013-08-30 01:59:53 +0000

                                     
2013-08-30
sqe info:
GS-Tonga/SNITest/SNITest1
GS-Tonga/SNITest/SNITest2
GS-Tonga/SNITest/SNITest3
GS-Tonga/SNITest/SNITest4
                                     
2013-09-03
URL:   http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/cdf68747b0fb
User:  lana
Date:  2013-09-18 00:31:25 +0000

                                     
2013-09-18
No failures of test/java/net/IDN/UseSTD3ASCIIRules.java	 in nightly:
http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures&parameters=%5BtestNameFilterRegExp%5Djava%2Fnet%2FIDN%2FUseSTD3ASCIIRules.java%5Bjdkproduct%5DJava%28TM%29%25%5Brelease%5D1.8.0%5Bbuild%5D%25%5Bvmproduct%5DJava%25VM%25%5Bvmrelease%5D%25%5Bvmbuild%5D%25%5Bcomponent%5D%25%5Btags%5D%25%5BstartDate%5DSep+10%2C+2009+1%3A00%3A00+AM+MSD%5BendDate%5DSep+10%2C+2020+1%3A00%3A00+AM+MSK%5BrunNames%5D%27%27%5BbatchNames%5D%27%27%5BbatchNameFilterRegExp%5D%25%5BrunNameFilterRegExp%5D%25%5BtestsuiteNameFilterRegExp%5D%25%5Bstatuses%5D%281%3D1%29%5Bmatches%5D%281%3D1%29%5Bbundles%5Dnone&splitting=%5BY+axis%5Dfailure%2C+reason%2C+productConfiguration%2C+release%2C+build%2C+date%2C+buildType%5BZ+axis%5D%5BX+axis%5Dos%2C+bitness%5BComplement%5Dvmrelease%2C+vmbuild%2C+VMVersionString%2C+JDKVersionString%2C+tags%2C+groups%2C+platform%2C+truncatedProductConfiguration%2C+VMMode%2C+JDKProfile%2C+VMFlavor%2C+hostname%2C+osFlavor%2C+osVersion%2C+buildDate%2C+msDate%2C+baseline%2C+emb_arch%2C+batch%2C+runName%2C+harness%2C+testbaseVersion%2C+testbase%2C+fullTestsuite%2C+testsuite%2C+component%2C+baselineName%2C+crs%2C+bugType%2C+duration&reference=%5BOthers%5Drelease%2C+build%2C+vmrelease%2C+vmbuild%2C+VMVersionString%2C+JDKVersionString%2C+tags%2C+groups%2C+platform%2C+truncatedProductConfiguration%2C+buildType%2C+bitness%2C+productConfiguration%2C+VMMode%2C+JDKProfile%2C+VMFlavor%2C+hostname%2C+os%2C+osFlavor%2C+osVersion%2C+date%2C+buildDate%2C+msDate%2C+baseline%2C+emb_arch%2C+batch%2C+runName%2C+harness%2C+testbaseVersion%2C+testbase%2C+fullTestsuite%2C+testsuite%2C+component%2C+baselineName%2C+failure%2C+reason%2C+crs%2C+bugType%2C+duration%5BReference+Set%5D&mixReference=false&flags=&significance=empty&hideDataConfiguration=false&calculateSummary=false&showSummaryExpanded=false&showSummaryContents=true&showComplementAttributes=false&compactTables=true&viewStyle=chessboard&filter_override=
                                     
2013-11-13
7u60-critical-request justification:

- Justification:
This bug fix is needed because the issue has been escalated by a customer (see the bugdb link above).

- Risk Analysis                :
The fix for 8 is applied cleanly to 7. The fix is quite straightforward, so the risk is low.

- Webrev:
http://cr.openjdk.java.net/~igerasim/8023881/0/webrev/

- Testing (done/to-be-done) :
The regression test is provided.
JPRT job finished successfully: everything compiles and all the regtests from jdk_net pass, including the one added.
                                     
2014-01-20
It was requested to backport this fix into 7 and 6.
Thus, creating the backport records.
                                     
2014-01-17



Hardware and Software, Engineered to Work Together