Name: nt126004 Date: 09/27/2002
FULL PRODUCT VERSION :
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)
FULL OPERATING SYSTEM VERSION :
glibc-2.2.5, linux 2.4.19, Mandrake8.3
ADDITIONAL OPERATING SYSTEMS :
A DESCRIPTION OF THE PROBLEM :
getResourceAsStream throws an exception with the following
resource name:
World/Fran?ais/Commerce_et_?conomie
It works fine with something like Arts/Television
(no utf-8 specific characters)
The problem is with how the
JNLPClassLoader makes HTTP GET requests - specifically how it encodes the
HTTP Request header. You see, while JWS deals with utf-8 fine internally, it
_mangles_ the HTTP Request header to the point where the JNLPDownloadServlet
receives unrecognizable characters!
Take a simple case:
http://localhost/sw/Fran?ais.jar
(note the strange 'c' character - I see your html forms destroyed this
utf-8/iso8859-1 character into a '?' ... hopefully your email client will be
able to see it)
JWS seems to deal with it just fine, until it asks a webserver for the jar.
JWS will then incorrectly create a request like this:
http://localhost/sw/Fran?ais.jar
(note the '?' instead of the '?')
You will note in rfc 1630 that only 7-bit ASCII characters are allowed in a
URI. Therefore JWS MUST call URLEncode() before using the URL to make a
connection.
http://www.ietf.org/rfc/rfc1630.txt?number=1630
There is no other way. This is simply how it is done.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.create Fran?ais.jar
2. try to specify this in a jnlp file
3.try to access something in the Fran?ais.jar with
getResourceAsStream() - it will fail.
4. using the jnlpdownloadservlet, it will not accept the
Fran?ais.jar as a valid name as the C (with an accent) character
is not parsed right.
EXPECTED VERSUS ACTUAL BEHAVIOR :
I expect to be able to be able to use Fran?ais.jar.
Actual, this is imopssible.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.IllegalArgumentException
at sun.net.www.ParseUtil.decode(ParseUtil.java:155)
at sun.net.www.protocol.file.Handler.openConnection(Handler.java:57)
at java.net.URL.openConnection(URL.java:943)
at sun.net.www.protocol.jar.JarURLConnection.<init>(JarURLConnection.java:64)
at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:24)
at java.net.URL.openConnection(URL.java:943)
at com.sun.javaws.security.JNLPClassPath.check(JNLPClassPath.java:355)
at
com.sun.javaws.security.JNLPClassPath$JarLoader.getResource(JNLPClassPath.java:495)
at
com.sun.javaws.security.JNLPClassPath.findNamedResource(JNLPClassPath.java:224)
at com.sun.javaws.security.JNLPClassPath.getResource(JNLPClassPath.java:265)
at com.sun.jnlp.JNLPClassLoader$2.run(JNLPClassLoader.java:400)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.jnlp.JNLPClassLoader.findResource(JNLPClassLoader.java:398)
at java.lang.ClassLoader.getResource(ClassLoader.java:780)
at com.sun.jnlp.JNLPClassLoader.getResource(JNLPClassLoader.java:181)
at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:941)
at com.wss.calendar.client.swing.Main.test(Main.java:45)
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
Source - the main() method specifiied in the jnlp file:
public void test() throws Exception {
String resource = "World/Fran?ais/Commerce_et_?conomie";
System.out.println("resource (" + resource + ")");
ClassLoader cl = this.getClass().getClassLoader();
InputStream is = cl.getResourceAsStream(resource);
// The above getResourceAsStream will throw()
if (is == null)
throw new Exception( "Did not contain the required resource:" +
resource);
// you will never see this println output
System.out.println("Fran?ais/Commerce_et_?conomie worked!");
}
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
There was a work-around in 1.2-rc, but 1.2 has broken it. Now
there is no possible way to use utf-8 characters.
(Review ID: 164800)
======================================================================