Chrome v14 beta supports only IETF draft 10

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download Chrome 14 beta
2. Try to use the jwebsocket online chat demo. It doesn't work

In v14, Chrome dropped support for old web socket protocols and now only 
supports draft-ietf-hybi-thewebsocketprotocol-10, which fixes a security 
vulnerability.
http://blog.chromium.org/2011/08/new-websocket-protocol-secure-and.html

It looks like Revision r1734 (a few days ago) patches in support for the new 
protocol. Any chance of that getting released soon? I'm too lazy to compile 
from source. =P Your last v.10 release is over a year old now.

I don't know how long before v14 hits Chrome's stable channel. Possibly a month 
or two.

Nice app btw. =P

Original issue reported on code.google.com by cuc...@gmail.com on 20 Aug 2011 at 5:31

[GoogleCodeExporter]

Oooh, found the r1757 beta download. Thanks fivefeetfurther. I'll test it out.

Original comment by cuc...@gmail.com on 20 Aug 2011 at 5:47

[GoogleCodeExporter]

I got the jwebsocket server to start on my Tomcat app after a bit of tweaking 
(using the bundle jar in my WEB-INF/lib folder). I had to delete the 
javax.servlet API from the bundle .jar file.

Now I'm getting this exception when Chrome v14 tries to connect:

Exception in thread "jWebSocket TCP-Engine (8787, non secured)" 
java.lang.NoClassDefFoundError: com/sun/net/ssl/internal/ssl/SSLSocketImpl
    at org.jwebsocket.tcp.TCPEngine.processHandshake(TCPEngine.java:341)
    at org.jwebsocket.tcp.TCPEngine.access$200(TCPEngine.java:54)
    at org.jwebsocket.tcp.TCPEngine$EngineListener.run(TCPEngine.java:445)
    at java.lang.Thread.run(Thread.java:679)
Caused by: java.lang.ClassNotFoundException: 
com.sun.net.ssl.internal.ssl.SSLSocketImpl
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329)
    ... 4 more

It's a puzzling exception because I'm not using SSL in my app (using ws://, not 
wss://). Also, com.sun.net.ssl.internal.ssl.SSLSocketImpl doesn't seem to ship 
in the v6 openjdk JRE (default on most linux distros now). However, 
sun.security.ssl.SSLSocketImpl does.

I'm trying to see if I have any classpath issues that could cause this. I used 
to use Apache Ivy to manage this dependency, but I didn't bother trying to 
configure Ivy to use the beta jars. Maybe I'm missing a sub-dependency 
somewhere.

Original comment by cuc...@gmail.com on 20 Aug 2011 at 6:31

[GoogleCodeExporter]

Ok, now I'm just being nosy... A quick poke through your source dug up these 
lines, committed in r1600

Map lRespMap = WebSocketHandshake.parseC2SRequest(
lReq,
aClientSocket instanceof SSLSocketImpl);

Checking for the implementation behind the Socket interface might be 
JRE-specific. Is there another way to check for the SSL connection?

Original comment by cuc...@gmail.com on 20 Aug 2011 at 6:47

[GoogleCodeExporter]

Ok, I just had a thought. Why not do instanceof the javax.net.ssl.SSLSocket 
interface instead? That's part of the API and hence much more likely to be 
standard across JREs.

Original comment by cuc...@gmail.com on 20 Aug 2011 at 2:18

[GoogleCodeExporter]

FYI, Chrome 14 hit stable channel today for all platforms.

Apps based on v0.10 jWebSocket will not work for all users of Chrome stable. 
However, I noticed the chat demo now works with Chrome 14, so you must have 
gotten things to work with the new web socket protocol already.

I see v1.0 beta has been released too. The latest svn snapshot doesn't appear 
to fix this bug yet though.

Original comment by cuc...@gmail.com on 16 Sep 2011 at 8:31

[GoogleCodeExporter]

Yep i'm having the same issue with the SSLSocketImpl when running as standalone 
server (or with tomcat). 

Original comment by jarno.po...@gmail.com on 20 Sep 2011 at 9:49

[GoogleCodeExporter]

Confirmed that jWebSockets JavaScript API does not work in Chrome 14 (stable) 
on RedHat 5 and 6.  32-bit and 64-bit Chrome.

Original comment by chris.si...@gmail.com on 20 Sep 2011 at 3:16

[GoogleCodeExporter]

It looks like the changes in r1820 fix the java.lang.NoClassDefFoundError. If I 
can ever figure out how to compile this thing from source, I'll test it out and 
let you know.

Original comment by cuc...@gmail.com on 1 Oct 2011 at 3:30

[GoogleCodeExporter]

Finally figured out how Maven works, compiled from source, and confirmed that 
r1820 fixes the java.lang.NoClassDefFoundError

I found another bug tho, that I'll submit in a separate report (along with the 
fix)

Original comment by cuc...@gmail.com on 2 Oct 2011 at 5:56