Intermittent Error during WebSocket handshake: Unexpected response code: 400 on CloudBees

你说的曾经没有我的故事 提交于 2019-11-29 07:23:26

This is almost certainly due to not using https (SSL). Websocket over plain http is vulnerable to proxies in the middle (often transparent) operating at the http layer breaking the connection.

This is common on cellular networks, or office networks that may use multiple wireless connections with a proxy that spreads the http requests across connections.

The only way to avoid this is to use SSL all the time - this gives websocket the best chance of working.

Jean Sini

Adding to Michael Neale's solution.

As stated there, Play doesn't support WSS natively, as of late October, 2013.

So simply switching to SSL wouldn't work.

Thankfully, when configuring an app to use SSL, Cloudbees sets up an Nginx server as a router, with the SSL endpoint being the router, so the workaround described there will work.

So, once you create a custom domain name and corresponding Cloudbees app alias, set up your SSL certificates in a Cloudbees router, and configure your app to be use that Cloudbees router, you'll be able to connect to the websockets.

But you'll have to force the URLs to be secure, since using the regular Play route resolvers won't work. They return ws://..., not wss://... websockets URLs.

Specifically, using the out-of-the-box Play Framework sample Scala Websocket Chat app as an example:

  1. conf/routes defines:

    GET /room/chat controllers.Application.chat(username)
    
  2. Application defines:

    def chat(username: String) = WebSocket.async[JsValue] { request => ChatRoom.join(username) }
    
  3. and chatRoom.scala.js creates the web socket:

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

That won't work, since @routes....webSocketURL() will return a ws://, not a wss:// url.

chatRoom.scala.js can be modified as follows to make it work regardless of whether it's running within an https:// or http:// page:

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);

Hope this helps.

If it is intermittent, it might be that your client library has some trouble forming a valid handshake after a time. It would informative to run Wireshark to capture HTTP requests containing Connection: Upgrade headers to validate that the handshake request is valid.

For ways on how this could happen, see 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).
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!