2012-07-18 93 views
4

我們遇到了Chrome 19 websockets的問題。它正嘗試使用x-webkit-deflate-frame擴展名連接到我們的服務器。但是,我無法解決如何向客戶表明我們不支持該擴展(或者,如果它是Chrome 19的缺陷,並且忽略了我們不支持它的事實?)。我在幾個SO答案中看到了這個問題,但我看不到一致的解決方案。表示websocket服務器不支持任何擴展的標題

例如,如果我們收到的報頭

Upgrade: websocket 
Connection: Upgrade 
Host: titantest:30100 
Origin: http://titantest 
Sec-WebSocket-Key: f+7h4rrKKqdRRdD7WwTZow== 
Sec-WebSocket-Version: 13 
Sec-WebSocket-Extensions: x-webkit-deflate-frame 

我們應該以應對呢?

HTTP/1.1 101 Switching Protocols 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Accept: 3eazAhsFLXFWB1OjcYMtzP13yag= 

,然後附加到,我已經嘗試了各種Sec-WebSocket-Extension品種

Sec-WebSocket-Extension: '-' 
Sec-WebSocket-Extension: - 
Sec-WebSocket-Extension: 
<- blank: don't send a Sec-WebSocket-Extension header -> 

我也得到了我的面前WebSocket協議的副本,可以隨意地指出了我我錯過了/誤讀了。

回答

2

RFC 6455的第9.1節涉及擴展協商。

客戶端提出一個擴展列表,服務器從它想要接受的那些提議中選擇並使用其返回的Sec-WebSocket-Extensions標頭指示該選擇。通過在服務器握手響應中根本不包括擴展頭,它可以不接受任何東西。

當您返回無擴展頭時,chrome 19是否存在特定問題?

+0

不知道我怎麼錯過了那句話! Chrome 19仍然通過沒有'Sec-Websocket-Extensions'頭部的情況下返回我們的握手響應來發送消息,而我的印象是客戶端**必須掩蔽他們的websocket框架(至少在沒有延期已經談判)。它在Chrome 20和Chrome <= 18中似乎工作正常。 – dbeacham 2012-07-18 16:29:32

0

從響應中省略Sec-WebSocket-Extension是正確的選擇。

您還需要確保您取消屏蔽接收到的數據。如果你只是想接收文本,它會出現亂碼,除非它被揭露。

這個網站有關於如何揭露通過WebSocket連接接收到的數據很說明: http://lucumr.pocoo.org/2012/9/24/websockets-101/