> After this patch, I found I got "A turbulence detected!" as soon as I opened > the page, and BadCertificate errors in the log. > > To save others some debugging, the problem was that the patch changes the > domain in the wss:// URL from the domain used by the user to access the > site, to the one in http_frontend_public_address. > > Setting http_websocket_presented_address to match the value the client > enters fixes it (though I'm not sure this is reliable; if the client used an > IP address to access the server then it would fail again - they really have > to match).
Setting http_websocket_presented_address if there is a difference between where the backend listens, and where the frontend thinks it should be (e.g. load-balancer/firewall inbetween) is the correct behaviour. If http_websocket_presented_address is not given, it defaults to http_websocket_public_address, which defaults to the first http_frontend_address if not given. > BTW, are we ready to merge the client SSL support yet? I re-merged with trunk (client-auth branch of my repo), and can confirm that it is working nicely with client-auth in Chrome 23.0.1262.0 (155673) on Linux, Firefox 17 on Linux (both are Dev channel). As for Windows: Chrome 22.0.1229.94 (Windows, Mac, Linux Stable channel). Firefox 16.0.1 also works. Alas, it didn't work in IE 10.0.9200.16384 on Windows 8, but nobody uses IE anyway... So, in short it seems to be working with all major browsers now on all systems, so it should be good to commit (which I will do soon then). It should work on XP as long as your certificate doesn't use SHA2. Ali Ps. On a slightly related note, SSL is still broken with the mobile version of Chrome on Android for some reason. (It seems to be related to the non-blocking IO method Jetty uses, and the limitations of Java 1.6 IIRC from when I last looked into this)
