JDK-8023881 : IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-08-28
  • Updated: 2014-10-15
  • Resolved: 2013-08-30
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.
JDK 6 JDK 7 JDK 8
6u81Fixed 7u60Fixed 8 b108Fixed
Related Reports
Duplicate :  
Relates :  
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
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.
20-01-2014

It was requested to backport this fix into 7 and 6. Thus, creating the backport records.
17-01-2014

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=
13-11-2013

sqe info: GS-Tonga/SNITest/SNITest1 GS-Tonga/SNITest/SNITest2 GS-Tonga/SNITest/SNITest3 GS-Tonga/SNITest/SNITest4
03-09-2013

I set this bug as P2 because it impacts the SNIHostName behavior a lot. See also JDK-8019785.
28-08-2013