我在CloudBees的運行WebSocket的應用程序 - 我間歇性地看到:間歇性錯誤:意外的響應代碼:400 CloudBees的
Error during WebSocket handshake: Unexpected response code: 400
我已經告訴它使用HTTP 1.1通過允許升級:
bees app:proxy:update http_version=1.1
它可以工作,但我有時會看到錯誤(並非總是)。
我在CloudBees的運行WebSocket的應用程序 - 我間歇性地看到:間歇性錯誤:意外的響應代碼:400 CloudBees的
Error during WebSocket handshake: Unexpected response code: 400
我已經告訴它使用HTTP 1.1通過允許升級:
bees app:proxy:update http_version=1.1
它可以工作,但我有時會看到錯誤(並非總是)。
這幾乎肯定是由於未使用https(SSL)。普通http上的Websocket容易受中間代理(通常是透明的)的影響,在http層中斷連接。
這在蜂窩網絡或辦公室網絡中很常見,它可能會使用多個無線連接與代理之間的連接傳播http請求。
避免這種情況的唯一方法是始終使用SSL - 這爲websocket提供了最佳工作機會。
添加到Michael Neale的解決方案。
如前所述there,播放不支持WSS本身,截至10月末,2013年
所以,簡單地切換到SSL是行不通的。
幸運的是,在配置應用程序以使用SSL時,Cloudbees將Nginx服務器設置爲路由器,SSL端點爲路由器,因此可以使用描述爲there的解決方法。
因此,一旦您創建了自定義域名和相應的Cloudbees應用別名,請在Cloudbees路由器中設置您的SSL證書,並將您的應用配置爲使用該Cloudbees路由器,您將能夠連接到Websockets 。
但是由於使用常規的播放路由解析器無法正常工作,因此您必須強制URL安全。他們返回ws:// ...,而不是wss:// ... websockets網址。
具體而言,使用了外的現成Play Framework sample Scala Websocket Chat app爲例:
CONF /路由定義:
GET /room/chat controllers.Application.chat(username)
應用定義:
def chat(username: String) = WebSocket.async[JsValue] { request => ChatRoom.join(username) }
和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。js可以修改如下,使其工作,無論它在https://或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);
希望這會有所幫助。
如果它是間歇性的,可能是因爲您的客戶端庫在一段時間後形成有效的握手時遇到了一些麻煩。它將提供信息來運行Wireshark捕獲包含Connection:Upgrade headers的HTTP請求,以驗證握手請求是否有效。
有關這是怎麼發生的方法,請參閱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).
它可能是 - 特定的情況下,這是一個遠程辦公室的人碰巧運行了兩個蜂窩連接 - 與一些代理將平衡他們之間。無論如何,SSL都在工作 - 所以它可以幫助解決這個問題。我相信在這種情況下,它是鉻 - 沒有使用過的庫。 –
使用WebSockets部署了一些公共應用程序後,wss://是一項要求,特別是對於美國主要的移動運營商網絡。 AT&T,Verizon,T-Mobile網絡在每條路線上都可能沒有WebSocket握手感知中介。 Chrome似乎已經很好地實現了WebSocket規範,所以我肯定會傾向於這些網絡問題。 – nowucca
不宜的X轉發,原標題告訴播放的連接是安全的 - 和寫作URL時使用WSS?如果它不 - 這是我認爲的一個遊戲錯誤。 –