Secure Websockets (WSS) problems


Has anybody tried WSS:// from script yet? I use the same server for WS,WSS,HTTP and HTTPS (HTTPS and WSS even use the same ports) and everything works fine except WSS. I need to find out of the problem is on my end or not. I am beginning to suspect it might be a problem with hifi because others using the same server software are saying they don’t have this problem.


Hi @Cracker_Hax have a look at this script it is what I used when I created this gif:


I see it uses ws, not wss. Did you try it with wss? I can get ws to work fine but not wss.


Also I have had a lot of people who aren’t connecting at all, some of whom can get ws to connect with echo test servers. Others have no problem with ws at all.

Sometimes it is because of their network setup and they can’t use ws even from their browser, but @thoys and I tested this, he got his working with an echo test server but it still would not work with mine.


Ok I just tested wss on an echo server and it connects fine, so hifi is not the problem (although we still need to look into why some users cannot use websockets and some can).


Ok I made a script here for testing websockets. Feel free to use this for whatever you want. It would probably be useful as a script users can find in the script examples (the old one doesn’t work anymore).

var wsUri = "ws://"; 
var wssUri = "wss://"; 

var connection;

function load(uri) {
	connection = new WebSocket(uri);

connection.onopen = function () {
    var send = "Hello, world!";
    print('Client (to '+uri+': ' + send);

connection.onerror = function (error) {
    keepAlive = false;
    print('WebSocket error: ' + error);

connection.onmessage = function (e) {
    print('Server (from '+uri+': ' +;


Hey everyone!

We’re trying to figure out why some people can use websockets from hifi and others can’t. If you can post pertinent stats about your setup (network stats, location, OS, firewall, etc) and whether you can or cannot get websockets to work, that would be super helpful as we prepare for the winter games!



I run windows 10 with a DSL modem/router from the East Coast USA and I can use websockets.


I’ve just run Cracker’s test script from my system here near Santa Cruz and both the ws and wss versions seem to work fine.

I am on win 7 professional, minimal win firewall and a comcast cable connection with my own modem and router.

oops, just noticed that both just echo… but anyway, seem to work.


Any progress with this?


I tried running both WS & WSS, all work OK.
E.g., Server (from ws:// Hello, world!

Windows 10 Pro, Interface 3645
Connection is from Santa Cruz 802.11n to Netgear Nighthawk X6, to 1G 24-port NetgearPro switch to 1G gateway to mountain-top linux gateway running modified 802.11a radios on a dedicated 5 mile beam, then three hops to in San Jose, CA. is 19 hops away.


I’ve also had trouble with WSS and in my situation was able to narrow it down to SSL certificate issues.

The same also prevented XHR (HTTPS) from working – which became a reliable way to detect the situation.

Given an (allegedly) invalid certificate, both WebSocket and XHR currently fail silently. XHR changes to { readyState: DONE, status: 0, responseText: ""} and does not enter the error state (or trigger onerror). However, there’s a non-standard and useful .errorCode property that gets set to 6 in this case – which from QT headers means QNetworkReply::SslHandshakeFailedError.

So to check for this kind of cert issue becomes:

var endpoint = 'wss://endpoint:8080/asdf';

var xhr = new XMLHttpRequest();'GET', endpoint.replace(/^ws/,'http'), false);
if (!xhr.status && xhr.errorCode === 6)
  throw new Error('SslHandshakeFailedError');


@ericrius1 does HiFi use QTWeb websockets? If so I think the problem may be that it uses [draft-hixie-thewebsocketprotocol-76]
which uses an obsolete handshake request header

Sec-WebSocket-Key1: 8crO\J;4 136bp&m?b0441
Sec-WebSocket-Key2: 2746E 3218 \4/I2PmI |

While RFC 6455 standard Websocket protocol uses:

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Also if you use a http proxy, it might translate ws from the hixie draft to the official standard, while this is not possible for https and wss.


From documentation:

QWebSocket currently does not support extensions and subprotocols.

QWebSocket only supports version 13 of the WebSocket protocol, as outlined in RFC 6455.

Note: Some proxies do not understand certain HTTP headers used during a WebSocket handshake. In that case, non-secure WebSocket connections fail. The best way to mitigate against this problem is to use WebSocket over a secure connection.

Warning: To generate masks, this implementation of WebSockets uses the cryptographically insecure qrand() function. For more information about the importance of good masking, see The best measure against attacks mentioned in the document above, is to use QWebSocket over a secure connection (wss://). In general, always be careful to not have 3rd party script access to a QWebSocket in your application.

… but the problem with that is apparently mac users have a problem with wss.

Or the problem could have something to do with timeouts (this code change being up for review for QT 5.6)