-
Bug
-
Resolution: Fixed
-
P4
-
6u10
-
b97
-
x86
-
windows_vista
-
Verified
FULL PRODUCT VERSION :
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Vista SP1
A DESCRIPTION OF THE PROBLEM :
java.net.URI fails to quote character code 0 when it is used in a multi-argument constructors.
The bug in the source is fairly obvious. match looks like this:
private static boolean match(char c, long lowMask, long highMask) {
if (c < 64)
return ((1L << c) & lowMask) != 0;
if (c < 128)
return ((1L << (c - 64)) & highMask) != 0;
return false;
}
But the zero-th bit is special:
// The zero'th bit is used to indicate that escape pairs and non-US-ASCII
// characters are allowed; this is handled by the scanEscape method below.
private static final long L_ESCAPED = 1L;
private static final long H_ESCAPED = 0L;
match() needs code to handle the zero-th bit; for example, you could add
if (c == 0) return false;
as the first line of match().
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the supplied source code.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
0:http://example.com/%00
1:http://example.com/%01
ACTUAL -
0:http://example.com/(a nul character is here)
1:http://example.com/%01
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.net.URI;
import java.net.URISyntaxException;
public class URIBug {
static public void main(String[] args) throws URISyntaxException {
System.out.println("0:" + new URI("http", "example.com", "/\u0000", null));
System.out.println("1:" + new URI("http", "example.com", "/\u0001", null));
}
}
---------- END SOURCE ----------
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Vista SP1
A DESCRIPTION OF THE PROBLEM :
java.net.URI fails to quote character code 0 when it is used in a multi-argument constructors.
The bug in the source is fairly obvious. match looks like this:
private static boolean match(char c, long lowMask, long highMask) {
if (c < 64)
return ((1L << c) & lowMask) != 0;
if (c < 128)
return ((1L << (c - 64)) & highMask) != 0;
return false;
}
But the zero-th bit is special:
// The zero'th bit is used to indicate that escape pairs and non-US-ASCII
// characters are allowed; this is handled by the scanEscape method below.
private static final long L_ESCAPED = 1L;
private static final long H_ESCAPED = 0L;
match() needs code to handle the zero-th bit; for example, you could add
if (c == 0) return false;
as the first line of match().
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the supplied source code.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
0:http://example.com/%00
1:http://example.com/%01
ACTUAL -
0:http://example.com/(a nul character is here)
1:http://example.com/%01
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.net.URI;
import java.net.URISyntaxException;
public class URIBug {
static public void main(String[] args) throws URISyntaxException {
System.out.println("0:" + new URI("http", "example.com", "/\u0000", null));
System.out.println("1:" + new URI("http", "example.com", "/\u0001", null));
}
}
---------- END SOURCE ----------