Error during WebSocket handshake

1,583 views
Skip to first unread message

rdaf.richard

unread,
Jul 6, 2012, 12:51:21 PM7/6/12
to soc...@googlegroups.com

When using an SSL connection with Safari / SockJS / vertx, I'm getting the error below (in both Safari iOS and desktop versions). SockJS then downgrades to xhr-streaming.

Error during WebSocket handshake: location mismatch: wss://xxx.yyy.com/vertx/151/17oni93k/websocket != ws://xxx.yyy.com /vertx/151/17oni93k/websocket 

I'm using vertx as the SockJS server.  The exact same connect in Chrome works fine and establishes a secure Websocket connection. When using a straight HTTP connection (i.e. not encrypted) with Safari / SockJS / vertx, Safari will establish a Websocket connection.

Any suggestions for getting Safari to establish a secure Websocket connection with SockJS / vertx?

Thanks,

-Randall

Marek Majkowski

unread,
Jul 6, 2012, 12:57:38 PM7/6/12
to rdaf.r...@gmail.com, Tim Fox, soc...@googlegroups.com
Hi!

First, it's good that sockjs downgrades correctly :)

Second, yes, indeed, Safari (as opposed to chrome) seems to expect
wss:// in the header during websockets handshake over SSL.
This is in the websockets spec, but chrome is fine without it.

A Sockjs server should indeed send wss:// thing.

For Sockjs-node, we're using faye-websocket-node, which
uses the following code to detect if the connection was over ssl:
https://github.com/faye/faye-websocket-node/blob/master/lib/faye/websocket.js#L25

In other words: it looks for a 'x-forwarded-proto' header from a loadbalancer.


Tim,

what's the situation in vert.x? Can vert.x do SSL termination?
If so, then is vert.x sending wss:// during the ws handshake over SSL?

Additionally, in the case of load balancer doing SSL termination,
could vert.x adhere to ''x-forwarded-proto'' header?

Cheers,
Marek

Marek Majkowski

unread,
Jul 11, 2012, 7:25:35 PM7/11/12
to Randall Richard, SockJS
On Wed, Jul 11, 2012 at 9:01 PM, Randall Richard <rdaf.r...@gmail.com> wrote:
> Need some help. It looks as though the iPad and iPhone never make it to
> the Websocket handshaking stage when using secure Websockets. I've been
> studying the vertx / SocksJS code but not understanding where / how the
> SocksJS downgrading process takes place. From what I can tell, the initial
> https:// based connection request step is failing very early in the process
> and the SocksJS Javascript code is gracefully stepping down and
> re-requesting a connection with xhr-streaming.
>
> As mentioned, Safari desktop on both Windows and Mac establish secure
> connections fine now with the change I made. Interestingly, iOS and desktop
> Safari report the same Websocket protocol version draft-76 per
> http://websocketstest.com. BTW, the iPad and iPhone pass the SSL connection
> test on http://websocketstest.com.

Hi,

Please try running:
https://sockjs.popcnt.org/example-cursors.html
and
https://sockjs.popcnt.org/tests-qunit.html

To verify if sockjs + sockjs-node are working fine in your environment.

Marek
Reply all
Reply to author
Forward
0 new messages