2012-03-13 9 views
3

私は単純なWebSocketサーバーをPythonで書いています。これはポートで待機し、ハンドシェイクを実行してから番号を含む一連のメッセージ(ランダムな間隔で配置されています)をクライアントに送信します。クライアントが使用するwebsocketのバージョンを知るには?

私はjavascriptクライアントを作成し、ChromeとSafariでテストしました。私は、ChromeとSafariが異なるWebSocketバージョンを使用していることを発見しました。たとえば、ChromeはSec-WebSocket-Key(Sec-WebSocket-Accept)を使用し、SafariはSec-WebSocket-Key1、Sec-WebSocket-Key2、およびヘッダーの後に8バイトの束を送信します。

私はサーバーに、必要なハンドシェイクの種類を検出して実行するハンドシェイク機能を実装しました。この問題は解決されました。 websocketは、ChromeまたはSafari(OSX、Windows、IOS5の両方)から正しく開きます。

しかし、別の問題があります。明らかにSafariは0x00と0xFFで区切られたメッセージを送信し、期待していますが、Chromeはフレーム同期およびマスクされたデータを送信し、期待しています(WebSocket仕様のより新しいバージョンを使用)。

私は、クライアントの期待にそれ自身を適応させる単一のサーバーを使いたいと思っています。私の質問は、データがフレーム化されているか0x00,0xFFで区切られているかどうかを事前にどのように伝えることができますか?

私は、ハンドシェイクプロトコルがKey1とKey2をベースにしている場合、クライアントはSafariで、0x00 0xFFを使用してデータを区切ります.Sec-WebSocket-Keyを使用するクライアントはChromeですが、フレーム化されたデータを使用します。しかし、一般的ではないので、私はこの解決策に満足していません。アイデア?

答えて

3

Chromeなどで使用されているSafari(デスクトップ&モバイル)とRFC 6455で使用されているhixie-76プロトコルのバリエーションの両方に公開されている標準があります。

要求されたハンドシェイクのタイプを使用して、クライアントが話すプロトコルバージョン、メッセージの読み込みにどのフレームが存在するのか、メッセージの書き込みに使用するフレームを決定できます。

+0

リンクありがとうございます。私が正しく理解していれば、「WebSocket-Version」やそれに類するヘッダはなく、使用しているバージョンを手動で検出するためのアドホックコードを書くべきでしょうか? – JLDiaz

+1

それは正しいです。 (RFCの後半にバージョンヘッダがありますが、ChromeとSafariの両方で適切なヘッダーはありません)。私はSec-WebSocket-Key1ヘッダーを使ってhixie-76(Safari)を推論するシンプルなwebsocketサーバーを持っています。 RFC 6455(Chrome)を推測するSec-WebSocket-Keyヘッダー – simonc

+3

これは正しくありません。何か> = Hybi.10の場合、ヘッダーはChrome、Firefox、WebKit Nightly、IE10 .. Sec-WebSocket-Versionによって送信されます。彼らは8または13を送信します。このヘッダーは古いHixie-76には存在しませんが、廃止予定のバージョンに残っている唯一のものはSafariです。 Webkit NightlyはRFC6455を持っています。 見てください:http://autobahn.ws/testsuite/reports/clients/index.html ブラウザごとにケース1.1.1をクリックし、WebSocketハンドシェイクまでスクロールダウンします。 免責事項:私はAutobahnの著者であり、Tavendoの仕事をしています。 – oberstet

-1

シンプル:WebSocketのバージョンは1つだけです。残りは下書きです。 RFCが廃止されたので、あなたは何も実装しないことを正式に推奨しています。 FirefoxとChromeの最新バージョンはどちらもRFCバージョンを実装しており、自動更新します。ドラフトはクライアントによって非常に迅速に使用されなくなるので、少しでも相互運用性を得るためにもそれらを実装しようとしても意味がありません。

これらはもう関連性がなく、クルフトを追加します。ドラフトが引き続きサポートされるべきであるということは、ブラウザベンダーのいずれかによって進められているわけではありません。確かに、Mozillaはwebsocketオブジェクトのプレフィックスを変更する前に仕様まで待っていました。同様に、ブラウザベンダーは、ドラフト用に作成されたアプリケーションは、実動コードではなくデモでなければならず、クライアントコードのドラフトをサポートする以上にドラフトサーバーをサポートする予定はないとしています。

したがって、1つの仕様に固執し、ドラフトの初期実装については忘れてください。

+2

モバイルで実行したい場合は、実際のオプションではありません。 – kybernetikos

+1

@kybernetikosに同意します。モバイルブラウザに最新のプロトコルを採用したバージョンが出現するまでは、古いプロトコルを現在のプロトコルと同時にサポートする必要があります。 – dlchambers

1

私は同じ必要性を持っていたので、私はwindow.WebSocket.CLOSEDが最新の実装で3に等しいことを発見しました。古いものは2(Androidネイティブブラウザの例)です。

だから私は今、最新のWebSocketプロトコルのサポートを検出することテストは次のとおりです。

if('WebSocket' in window 
    &&'function' === typeof window.WebSocket 
    &&3 === window.WebSocket.CLOSED) { 
// hurra ! 
} 

私はクロム、Firefoxの(それが成功する場所)にして(それが失敗した)Androidのブラウザでそれをテストしました。それがいくつかの人々に役立つことを願っています。

関連する問題