搜尋 Mozilla 技術支援網站

防止技術支援詐騙。我們絕對不會要求您撥打電話或發送簡訊,或是提供個人資訊。請用「回報濫用」功能回報可疑的行為。

了解更多

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

  • 1 回覆
  • 6 有這個問題
  • 2 次檢視
  • 最近回覆由 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.

從原來的回覆中察看解決方案 👍 0

所有回覆 (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.