Why does Firefox reject my servers websocket upgrade request? (It works using Chrome)
I have a simple web page that I'm using to test my server's websocket handling.
<meta charset="utf-8" /> <title>WebSocket Test</title> <script language="javascript" type="text/javascript">
var wsUri = "ws://192.168.1.18/"; var output;
function init()
{
output = document.getElementById("output");
testWebSocket();
}
function testWebSocket()
{
websocket = new WebSocket(wsUri);
websocket.onopen = function(evt) { onOpen(evt) };
websocket.onclose = function(evt) { onClose(evt) };
websocket.onmessage = function(evt) { onMessage(evt) };
websocket.onerror = function(evt) { onError(evt) };
}
function onOpen(evt)
{
writeToScreen("CONNECTED");
doSend("WebSocket rocks");
}
function onClose(evt)
{
writeToScreen("DISCONNECTED");
}
function onMessage(evt)
{
writeToScreen('RESPONSE: ' + evt.data+'');
websocket.close();
}
function onError(evt)
{
writeToScreen('ERROR: ' + evt.data);
}
function doSend(message)
{
writeToScreen("SENT: " + message);
websocket.send(message);
}
function writeToScreen(message)
{
var pre = document.createElement("p");
pre.style.wordWrap = "break-word";
pre.innerHTML = message;
output.appendChild(pre);
}
window.addEventListener("load", init, false);
</script>
WebSocket Test
If open the websocket with my devices url "ws://192.168.1.18/" the handshake fails. The handshake messages in this case are:
GET / HTTP/1.1 Host: 192.168.1.18 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:39.0) Gecko/20100101 Firefox/39.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Sec-WebSocket-Version: 13 Origin: null Sec-WebSocket-Extensions: permessage-deflate Sec-WebSocket-Key: GbRP0PQ/whahCSMaoHI5Jw== Connection: keep-alive, Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket
HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: g0yxJo5ra/Tt9XEVw/CYE6TL6k4= Server: CC3200 Access-Control-Allow-Origin: null Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: content-type Access-Control-Allow-Headers: authorization Access-Control-Allow-Headers: x-websocket-version Access-Control-Allow-Headers: x-websocket-protocol Access-Control-Allow-Headers: x-websocket-extensions
If I use chrome and do the exact same thing it works correctly. The handshake messages in this case are:
GET / HTTP/1.1 Host: 192.168.1.18 Connection: Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket Origin: null Sec-WebSocket-Version: 13 User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 Sec-WebSocket-Key: 44DCQu5HGWHJhfmheLHLUQ== Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: g0yxJo5ra/Tt9XEVw/CYE6TL6k4= Server: CC3200 Access-Control-Allow-Origin: null Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: content-type Access-Control-Allow-Headers: authorization Access-Control-Allow-Headers: x-websocket-version Access-Control-Allow-Headers: x-websocket-protocol Access-Control-Allow-Headers: x-websocket-extensions
If I change the websocket.html to open the web socket with the following url "ws://echo.websocket.org" and use Firefox it works correctly. The handshake messages in this case are:
GET / HTTP/1.1 Host: echo.websocket.org User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:39.0) Gecko/20100101 Firefox/39.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Sec-WebSocket-Version: 13 Origin: null Sec-WebSocket-Extensions: permessage-deflate Sec-WebSocket-Key: IEacmz7ymUm9hVUwiBKgKQ== Cookie: __utma=9925811.1152089919.1439739052.1439739052.1439764138.2; __utmc=9925811; __utmz=9925811.1439739052.1.1.utmcsr=yahoo|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided) Connection: keep-alive, Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket
HTTP/1.1 101 Web Socket Protocol Handshake Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: content-type Access-Control-Allow-Headers: authorization Access-Control-Allow-Headers: x-websocket-extensions Access-Control-Allow-Headers: x-websocket-version Access-Control-Allow-Headers: x-websocket-protocol Access-Control-Allow-Origin: null Connection: Upgrade Date: Tue, 18 Aug 2015 02:25:59 GMT Sec-WebSocket-Accept: 8lhhE/W/ZeYJCwIZDl5NkPf0ImI= Server: Kaazing Gateway Upgrade: websocket
I can't find a difference between the working and non-working responses other than the order of the data and the presence of a date field and the server value being my CC3200 based device.
The socket close evt for the the failure case has a 1006 value for the code.
Chosen solution
I am using a TI CC3200 to run the webserver code.
It turns out TI's implementation expects to find the upgrade header followed by the key in the request. That is why it was working for chrome.
FireFox has the key before the upgrade header. The TI code was missing the key and just using a null string for it. So the accept response had something looking reasonable but was wrong.
It would have been nice if firefox would have output something about the accept data being wrong.
Anyway, TI is aware of the issue.
Read this answer in context 👍 0All Replies (1)
Suluhisho teule
I am using a TI CC3200 to run the webserver code.
It turns out TI's implementation expects to find the upgrade header followed by the key in the request. That is why it was working for chrome.
FireFox has the key before the upgrade header. The TI code was missing the key and just using a null string for it. So the accept response had something looking reasonable but was wrong.
It would have been nice if firefox would have output something about the accept data being wrong.
Anyway, TI is aware of the issue.