ابحث في الدعم

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Why does Firefox reject my servers websocket upgrade request? (It works using Chrome)

  • 1 (رد واحد)
  • 6 have this problem
  • 2 views
  • آخر ردّ كتبه couellette

more options

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.

I have a simple web page that I'm using to test my server's websocket handling. <!DOCTYPE html> <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('<span style="color: blue;">RESPONSE: ' + evt.data+'</span>'); websocket.close(); } function onError(evt) { writeToScreen('<span style="color: red;">ERROR:</span> ' + 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> <h2>WebSocket Test</h2> <div id="output"></div> 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.

الحل المُختار

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 👍 0

All Replies (1)

more options

الحل المُختار

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.