Applet loading errors (AIX/HTTPS only??)

[Tom Katz]

Web Client loads an applet (Main.class) and seems to work fine on windows/solaris https services.

Seeing the below console info when applet is not loaded from a set of AIX services running https.


Console output
=============================================
network: Connecting https://server:15004/cm/Main.class with proxy=DIRECT
network: Connecting https://server:15004/cm/Main/class.class with proxy=DIRECT
load: class Main.class not found.
java.lang.ClassNotFoundException: Main.class
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadCode(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: open HTTP connection failed.
at sun.applet.AppletClassLoader.getBytes(Unknown Source)
at sun.applet.AppletClassLoader.access$100(Unknown Source)
at sun.applet.AppletClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
... 10 more
=============================================

See the 'Main/class.class' which I think *must* be the crux of the problem.

I checked source code from the loading page on both working and non-working services, and they matched up:

    
document.writeln("  <PARAM NAME=\"CODE\" VALUE=\"Main.class\">");

Oh, also, this doesnt happen for all clients, someone running Vista can open it, while two of us (running XP) can't. Ironically, the Vista machine has the older version of Internet Explorer.


[ February 19, 2008: Message edited by: Tom Katz ]

[Ulf Dittmer]

The "https://server:15004/cm/Main/class.class" may just be a consequence of "https://server:15004/cm/Main.class" not being found, and not the source of the problem.

(To elaborate, there are two ways to specify the class name, either "code=Main" or "code=Main.class". Both are used by various implementations, so if the JVM sees "Main.class" it doesn't know whether the class name is "Main" or if the class name is "class" in a package called "Main". So it tries both wyas.)

Have you tried using an APPLET tag instead of an OBJECT tag?

One thing to investigate -if the problem is repeatable- would be to check the access logs of the web server to see if the request for the class file is actually getting to the web server.

[Tom Katz]

Thank you for the ideas. I'm going to first take .class out of the OBJECT tag.

I might try the applet tag as well - as long as it can do everything the OBJECT tag can (enforce JRE level, etc.) I don't see why we haven't been using it yet.

[Tom Katz]

One thing I was also going to mention. Along with all the weirdness around what circumstances cause this. If I call the JSP which loads the applet directly (its part of a frameset) using http, the applet loads fine.

[Tom Katz]

Request Log from jetty:

UNSUCCESSFUL:
"GET /cm/cm.html HTTP/1.1" 304 0
"GET /cm/frame1.html HTTP/1.1" 304 0
"GET /cm/frame3 HTTP/1.1" 200 1229
"GET /cm/frame4 HTTP/1.1" 200 1956
"GET /cm/frame2 HTTP/1.1" 200 2528
"GET /cm/mqs.png HTTP/1.1" 304 0
"GET /cm/qlogo.png HTTP/1.1" 304 0
"GET /cm/web_cm.js HTTP/1.1" 304 0
"GET /cm/applet_jre_version.js HTTP/1.1" 304 0
"GET /cm/link_left_active.gif HTTP/1.1" 304 0
"GET /cm/link_right_active.gif HTTP/1.1" 304 0
"GET /cm/link_left_inactive.gif HTTP/1.1" 304 0
"GET /cm/link_right_inactive.gif HTTP/1.1" 304 0
"GET /cm/qsplash.png HTTP/1.1" 304 0

SUCCESSFUL:
"GET /cm/cm.html HTTP/1.1" 304 0
"GET /cm/frame1.html HTTP/1.1" 304 0
"GET /cm/frame2 HTTP/1.1" 200 2528
"GET /cm/frame3 HTTP/1.1" 200 1229
"GET /cm/frame4 HTTP/1.1" 200 1956
"GET /cm/mqs.png HTTP/1.1" 304 0
"GET /cm/qlogo.png HTTP/1.1" 304 0
"GET /cm/applet_jre_version.js HTTP/1.1" 304 0
"GET /cm/web_cm.js HTTP/1.1" 304 0
"GET /cm/link_left_active.gif HTTP/1.1" 304 0
"GET /cm/link_left_inactive.gif HTTP/1.1" 304 0
"GET /cm/link_right_active.gif HTTP/1.1" 304 0
"GET /cm/link_right_inactive.gif HTTP/1.1" 304 0
"GET /cm/qsplash.png HTTP/1.1" 304 0
"GET /cm/WebCmApplet.jar HTTP/1.1" 304 0


The major difference is that the unsuccessful one, you don't see a request for the .jar. Also, the order of requests for frameset JSPs and .js files it slightly out of order.

another twist - turns out the clients that were working, were running Java 6 JRE (which our product doesnt support yet) - once they installed our supported JRE (150.11) the error was seen.

So, it's 1.5/AIX/SSL specific problem

I'm working on using the applet tag (in place of object tag) to try to resolve this.

[Tom Katz]

Nothing doing yet . .
*tried adding a java_codebase param to object tag ('/cm')
*tried using jsp lugin tag

The HTTPS/SSL is part of this, and I'm not sure why yet.

- This works on windows/solaris, http or https
- It works on aix when using an http url, but as soon as it's https:

Caused by: java.io.IOException: open HTTP connection failed.

"HTTP Connection failed" ?? hmmmm

[Tom Katz]

Realized I also/instead need to be checking this out from the server end - in the structure of the .war file, maybe?

[Ulf Dittmer]

Two more random ideas:

Use a tool like Ethereal to check whether the request for the jar file ever gets sent by the client machine.

Since the problem is with Java 1.5/AIX/HTTPS -which is a very specific set of circumstances- check if the AIX Java 1.5 JVM has a known bug in this area.

[Tom Katz]

I have seen the issue on a separate AIX machine, same factors all apply.

I am getting a lot of information in the jetty log now, using some debug flags (see excerpt below)

*javax.net.ssl.SSLHandshakeException: Client requested protocol SSLv3 not enabled or not supported*
I see this after the GET request for the last file before the .jar GET request should come in.

**
I've got a bit of a learning curve using sharkwire (but it will be worth it, great tool), still trying to determine whether the client is making the request for the .jar.

LOG:

INFO | jvm 1 | 2008/02/22 17:12:15 |
INFO | jvm 1 | 2008/02/22 17:12:15 | btpool0-7, READ: SSL v2, contentType = Handshake, translated length = 73
INFO | jvm 1 | 2008/02/22 17:12:15 | *** ClientHello, SSLv3
INFO | jvm 1 | 2008/02/22 17:12:15 | RandomCookie: GMT: 1186944463 bytes = { 140, 82, 140, 186, 150, 195, 84, 159, 1, 100, 81, 65, 207, 184, 110, 244, 251, 146, 118, 71, 206, 1, 228, 220, 12, 31, 37, 3 }
INFO | jvm 1 | 2008/02/22 17:12:15 | Session ID: {}
INFO | jvm 1 | 2008/02/22 17:12:15 | Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
INFO | jvm 1 | 2008/02/22 17:12:15 | Compression Methods: { 0 }
INFO | jvm 1 | 2008/02/22 17:12:15 | ***
INFO | jvm 1 | 2008/02/22 17:12:15 | btpool0-7, SEND TLSv1 ALERT: fatal, description = handshake_failure
INFO | jvm 1 | 2008/02/22 17:12:15 | btpool0-7, WRITE: TLSv1 Alert, length = 2
INFO | jvm 1 | 2008/02/22 17:12:15 | [Raw write]: length = 7
INFO | jvm 1 | 2008/02/22 17:12:15 | 0000: 15 03 01 00 02 02 28 .......
INFO | jvm 1 | 2008/02/22 17:12:15 |
INFO | jvm 1 | 2008/02/22 17:12:15 | btpool0-7, called closeSocket()
INFO | jvm 1 | 2008/02/22 17:12:15 | btpool0-7, handling exception: javax.net.ssl.SSLHandshakeException:
Client requested protocol SSLv3 not enabled or not supported
INFO | jvm 1 | 2008/02/22 17:12:15 | btpool0-7, called close()
INFO | jvm 1 | 2008/02/22 17:12:15 | btpool0-7, called closeInternal(true)
INFO | jvm 1 | 2008/02/22 17:12:15 | JsseJCE: Using MessageDigest MD5 from provider IBMJCE version 1.2
INFO | jvm 1 | 2008/02/22 17:12:15 | JsseJCE: Using MessageDigest SHA from provider IBMJCE version 1.2
INFO | jvm 1 | 2008/02/22 17:12:15 | btpool0-6 - Acceptor0 [email protected]:15004, setSoTimeout(0) called

**
?? Maybe this should be in a different forum now? not sure..

thanks,
Tom

[ February 22, 2008: Message edited by: Tom Katz ]
[ February 22, 2008: Message edited by: Ulf Dittmer ]

[Ulf Dittmer]

*javax.net.ssl.SSLHandshakeException: Client requested protocol SSLv3 not enabled or not supported*

That seems like a good starting point for further investigation. You might try a different SSL version (e.g., Firefox lets you turn off SSLv3 and/or TLSv1 in the Advanced -> Encryption tab).

Plus, check the AIX server software which SSL encryption protocol versions it supports.

[Tom Katz]

I see some differences between the successful (java 6) and unsuccessful (java 5) client's 'cached cipher entries:

Cached server session: [Session-#, SSL_RSA_WITH_*]

Request from java 5 clients (not working), before the handshake_failure:
SSL_RSA_WITH_AES_128_CBC_SHA

Request from java 6 client (works), before the .jar is downloaded:
SSL_RSA_WITH_RC4_128_MD5

BTW: tried using the latest (SR6) JRE on the aix box and no change in behavior.

[Tom Katz]

Works now - I had to configure Jetty's SslSocketConnector to use SSLv3:

<Set name="protocol">SSLv3</Set>

Thanks for the help Ulf

[Ulf Dittmer]

You're welcome, and thanks for reporting back the solution. Might save someone else a lot in investigation down the road.