2014-01-24 76 views
5

我在CloudBees的运行WebSocket的应用程序 - 我间歇性地看到:间歇性错误:意外的响应代码:400 CloudBees的

Error during WebSocket handshake: Unexpected response code: 400 

我已经告诉它使用HTTP 1.1通过允许升级:

bees app:proxy:update http_version=1.1 

它可以工作,但我有时会看到错误(并非总是)。

回答

20

这几乎肯定是由于未使用https(SSL)。普通http上的Websocket容易受中间代理(通常是透明的)的影响,在http层中断连接。

这在蜂窝网络或办公室网络中很常见,它可能会使用多个无线连接与代理之间的连接传播http请求。

避免这种情况的唯一方法是始终使用SSL - 这为websocket提供了最佳工作机会。

1

添加到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为例:

  1. CONF /路由定义:

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

希望这会有所帮助。

+0

不宜的X转发,原标题告诉播放的连接是安全的 - 和写作URL时使用WSS?如果它不 - 这是我认为的一个游戏错误。 –

1

如果它是间歇性的,可能是因为您的客户端库在一段时间后形成有效的握手时遇到了一些麻烦。它将提供信息来运行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). 
+0

它可能是 - 特定的情况下,这是一个远程办公室的人碰巧运行了两个蜂窝连接 - 与一些代理将平衡他们之间。无论如何,SSL都在工作 - 所以它可以帮助解决这个问题。我相信在这种情况下,它是铬 - 没有使用过的库。 –

+2

使用WebSockets部署了一些公共应用程序后,wss://是一项要求,特别是对于美国主要的移动运营商网络。 AT&T,Verizon,T-Mobile网络在每条路线上都可能没有WebSocket握手感知中介。 Chrome似乎已经很好地实现了WebSocket规范,所以我肯定会倾向于这些网络问题。 – nowucca

相关问题