JDK-4715098 : All-numeric hostname in URI causes NumberFormatException
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.4.0,1.4.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2002-07-15
  • Updated: 2002-11-19
  • Resolved: 2002-11-19
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
1.4.2 mantisFixed
Related Reports
Duplicate :  
Description

Name: nt126004			Date: 07/15/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)


FULL OPERATING SYSTEM VERSION :
Linux 7.3

ADDITIONAL OPERATING SYSTEMS :
Windows 2000


A DESCRIPTION OF THE PROBLEM :
The code included below throws a NumberFormatException for
a "valid" URI.  I put valid in quotes because the domain
name in the URI doesn't follow the recommendations of RFC
1034.  Nevertheless, the domain does exist - but you can't
get there through Java.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the included source code.
2. Execute the class.
3. Observe the goofy exception.


EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: the uri should be printed.
Actual: exception.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.NumberFormatException: 8007456830
	at java.lang.Integer.parseInt(Integer.java:438)
	at java.lang.Integer.parseInt(Integer.java:476)
	at java.net.URI$Parser.scanByte(URI.java:3099)
	at java.net.URI$Parser.scanIPv4Address(URI.java:3129)
	at java.net.URI$Parser.parseIPv4Address(URI.java:3162)
	at java.net.URI$Parser.parseServer(URI.java:3065)
	at java.net.URI$Parser.parseAuthority(URI.java:2998)
	at java.net.URI$Parser.parseHierarchical(URI.java:2948)
	at java.net.URI$Parser.parse(URI.java:2904)
	at java.net.URI.<init>(URI.java:565)
	at Test.main(Test.java:8)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.net.*;

public class Test
{
  public static void main(String[] args)
  {
    try {
      URI u = new URI("http://8007456830.com");
      System.out.println("URI = '" + u + "'");
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
}
---------- END SOURCE ----------
(Review ID: 159374) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b08
14-06-2004

EVALUATION Actually, the RFC 1034 rule about a hostname not starting with a digit is obsolete as of RFC 1123 section 2.1. The URL/URI specifications have always referred to RFC 1123 so the URI in the bug description really is legal. In fact, the javadoc for the URI class states for the getHost() method what the syntax for a valid hostname is and the description allows hostname labels to begin with a digit as long as it is not the only label or the last label in the hostname The rule stated in the javadoc would allow for the URI example in the bug description. However, the rule given is not consistent with RFC 2396 which prohibits a leading digit in the rightmost label of a multi-part domain name but allows a simple hostname (only a single label with no dot characters) to contain a leading digit. The implementation currently begins parsing the host field as if it were a numeric IPv4 address assuming it doesn't start with '[' in which case it must be an ipV6 numeric address. This is fine except that the code (and code comments) in the method scanIPv4Address() in URI.java make unwarranted assumptions about hostnames starting with digits. The fix needs to correct scanIPv4Address() to match RFC 2396 hostname syntax and the javadoc for getHost() also needs to be updated. ###@###.### 2002-07-15 As Jeff indicated there is both an implementation bug and a need to relax the specification to align with the original intent of RFC 2396. As it turns out the implementation bug is fixed by 4671369 which is on the list for mantis. Hence this bug will track the specification change to allow host components that comprise only a single domain label be permitted to start with a number. ###@###.### 2002-07-16
16-07-2002