간헐적 오류 : 예기치 않은 응답 코드 : CloudBees

Question

을 400 나는 CloudBees에 웹 소켓 응용 프로그램을 실행하고 - 나는 간헐적으로 참조 : 나는 그것을 말한

Error during WebSocket handshake: Unexpected response code: 400 

업그레이드를 통해 할 수 있도록 HTTP 1.1을 사용 :

bees app:proxy:update http_version=1.1 

작동하지만 오류 (항상 아님)가 표시되는 경우가 있습니다.

Answer 1

이것은 거의 확실하게 https (SSL)을 사용하지 않았기 때문입니다. 일반 http를 통한 Websocket은 http 계층에서 작동중인 중간 (대개 투명) 프록시를 취약하게합니다.

이것은 셀룰러 네트워크 또는 연결을 통해 http 요청을 분산시키는 프록시와 함께 여러 개의 무선 연결을 사용할 수있는 사무실 네트워크에서 일반적입니다.

이 문제를 피할 수있는 유일한 방법은 항상 SSL을 사용하는 것입니다. 그러면 websocket이 최상의 작업 기회를 얻을 수 있습니다.

Answer 2

Michael Neale의 솔루션에 추가.

같이, 재생이

2013 그래서 간단하게 작동하지 않을 것입니다 SSL로 전환 10 월 말 기준으로, 기본적으로 WSS를 지원하지 않습니다 there을 밝혔다.

감사하게도 SSL을 사용하도록 앱을 구성하면 Cloudbees가 Nginx 서버를 라우터로 설정하고 SSL 끝점을 라우터로 설정하므로 설명 된 해결 방법이 there으로 작동합니다.

사용자 정의 도메인 이름과 해당 Cloudbees 앱 별칭을 만들고 Cloudbees 라우터에서 SSL 인증서를 설정하고 해당 Cloudbees 라우터를 사용하도록 앱을 구성하면 웹 소켓에 연결할 수 있습니다 .

그러나 일반 재생 경로 확인자를 사용하면 URL이 안전해야하므로 강제로 재생됩니다. wss : // ...가 아니라 wss : // ...를 반환합니다. websockets URL.

구체적 예로서 아웃 오브 박스 Play Framework sample Scala Websocket Chat app 사용 :

1. CONT/노선은 정의

   GET /room/chat controllers.Application.chat(username) 
   

2. 응용 정의

   def chat(username: String) = WebSocket.async[JsValue] { request => ChatRoom.join(username) } 
   

3. 및 chatRoom.scala.js가 웹 소켓을 만듭니다 :

   var WS = window['MozWebSocket'] ? MozWebSocket : WebSocket 
   var chatSocket = new WS("@routes.Application.chat(username).webSocketURL()") 
   

작동하지 않습니다, @routes 때문에 .... webSocketURL()는 WS를 반환합니다 : // 아니라 WSS : // URL로 표시됩니다.

chatRoom.scala.// 또는 http : // 페이지 :이 도움이

var WS = window['MozWebSocket'] ? MozWebSocket : WebSocket; 
var wsUrl = "@controllers.api.routes.PubSubController.chat(username).webSocketURL()"; 
if(window.location.protocol == "https:") wsUrl = wsUrl.replace("ws:","wss:"); 
var chatSocket = new WS(wsUrl); 

희망 JS는 관계없이이 HTTPS 내에서 실행 여부의 작동하도록 다음과 같이 수정 될 수 있습니다.

Answer 3

간헐적 인 경우 클라이언트 라이브러리가 잠시 후 유효한 핸드 셰이크를 구성하는 데 문제가있을 수 있습니다. Connection : Upgrade headers가 포함 된 HTTP 요청을 캡처하여 Wireshark를 실행하여 핸드 셰이크 요청이 유효한지 확인하는 것이 유익합니다.

이 일어날 수 있는지에 대한 방법을

, subsection 4.2.1 of the WebSockets RFC 6455:

The client's opening handshake consists of the following parts. If 
    the server, while reading the handshake, finds that the client did 
    not send a handshake that matches the description below (note that as 
    per [RFC2616], the order of the header fields is not important), 
    including but not limited to any violations of the ABNF grammar 
    specified for the components of the handshake, the server MUST stop 
    processing the client's handshake and return an HTTP response with an 
    appropriate error code (such as 400 Bad Request).