Name: viR10068 Date: 01/29/2004



RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax
(for example see ftp://ftp.isi.edu/in-notes/rfc2396.txt) says:
"...
2. URI Characters and Escape Sequences
  URI consist of a restricted set of characters, primarily chosen to
  aid transcribability and usability both in computer systems and in
  non-computer communications. Characters used conventionally as
  delimiters around URI were excluded.
...

2.4.1. Escaped Encoding
   An escaped octet is encoded as a character triplet, consisting of the
   percent character "%" followed by the two hexadecimal digits
   representing the octet code. For example, "%20" is the escaped
   encoding for the US-ASCII space character.
..."

The API spec for the java.net.URI says:
"A character is encoded by replacing it with the sequence of escaped
octets that represent that character in the UTF-8 character set. The
Euro currency symbol ('\u20AC'), for example, is encoded as "%E2%82%AC".
(Deviation from RFC 2396, which does not specify any particular character
set.)".

So valid java application should use this URI syntax.

But if class name has an unicode character and the plugin/ appletviewer
uses the http protocol to load classes then the result is the ClassFormatError
instead of the NoClassDefFoundError, for example.

After short investigation I found that the following takes place:
1) the plugin tries to load class that extends an interface with the
unicode character in name (u1E00). Note, these class and interface have
empty bodies.

2) the http server receives the 'GET' command with unknown symbol instead
of the escaped unicode character [%E1%B8%80 for u1E00] even if the browser
is set to "Always send URLs as UTF-8". Note, in the http server log files
this looks like a '?' when browsing through the text editor and in
the java console log it looks like a '|'.

3) the http server returns the error code 301 (HTTP_STATUS_MOVED) and new
URI (in the log file it looks like '/?' instead of '?' or '|')

4) the plugin tries to load class with the new URI and receives the
directory listing. The name of the directory is a part of URL preceeding
the unicode character in the original request.

5) the plugin classloader receives directory listing, tries to use it as a
requested class file and throws the ClassFormatError (Bad magic number).

Note, this bug is reproducible under appletviewer too.

http server log:
'129.144.235.123 - - [28/Jan/2004:18:02:22 +0600] "GET
/net/novo79/export/home/plugin/javasoft/sqe/tests/vm/classfmt/cpl/cplcls002/cplcls00206m5?
/cplcls00206m5i.class HTTP/1.1" 301 427
129.144.235.123 - - [28/Jan/2004:18:02:22 +0600] "GET
/net/novo79/export/home/plugin/javasoft/sqe/tests/vm/classfmt/cpl/cplcls002/cplcls00206m5/
?/cplcls00206m5i.class HTTP/1.1" 200 1175'


Affected JCK tests are:
vm/classfmt/cpl/cplcls002/cplcls00206m2/cplcls00206m2.html
vm/classfmt/cpl/cplcls002/cplcls00206m4/cplcls00206m4.html
vm/classfmt/cpl/cplcls002/cplcls00206m5/cplcls00206m5.html

How to reproduce:
1) Start JavaTest (java -jar javatest.jar)
2) Start the plugin or apletviewer with loading class through the http. For example,
CODEBASE="http://sqeel/java/re/jck/1.5/qac/latest/binaries/JCK-runtime-15/classes"
3) run the test. For example, vm/classfmt/cpl/cplcls002/cplcls00206m2/cplcls00206m2.html

======================================================================