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) 
======================================================================