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.