12

webSocket 接続用のサーバーを作成しようとしています。仕様 (75 ではなく 76) を注意深く読みました。ブラウザは地雷原を使用しています。

ブラウザで JavaScript から WebSocket を作成しようとすると、次のようになります。

var ws = new WebSocket("ws://localhost:8766/hoho");

ブラウザは次のように応答します

「Firefox は、ws://localhost:8766/hoho でサーバーへの接続を確立できません。」

私のサーバーは有効なクライアント ハンドシェイク リクエストを受け取り、レスポンスを返し、ブームになります。

サーバーで見つけることができるすべてのハンドシェイクの例を実行し、すべてのインスタンスで指定された応答を正確に一致させました。私は、戻りバイト ストリームが正しいと確信しています。コードのデバッグに助けは必要ありません。コードは意図したとおりに実行されています。ハンドシェイク プロトコルの使用をデバッグする助けが必要です。なぜなら、私が地雷原に正しい応答だと思うものを与えると、それは私を笑ってしまうからです。

私の質問はこれです: どうすればこれをデバッグできますか? 2つの可能性が考えられます。

  1. ハンドシェイクを拒否する理由を地雷原に教えてもらう方法はありますか?

  2. Web 上で動作しているパブリックな webSocket サーバー サービスはありますか? 存在する場合は、それをプロキシして、両方向のバイト ストリームを監視し、どこが違うかを把握できます。

誰かがこれらの方向性やその他のアイデアについて何かアイデアを持っていますか?

助けてくれてありがとう。

4

3 に答える 3

2

2番目の可能性について。はい、そこに websocket サーバーがあります。http://jwebsocket.org/demos/chat/chat.htmの jWebSocket デモ サーバー

お役に立てれば

追加: エコー ソケット サーバー: http://www.websocket.org/echo.html

于 2012-08-19T23:25:47.100 に答える
2

私は同様の状況をデバッグしている最中であり、私が最も頼りにしているツールは netcat で、openssl を追加で使用しています。Websocket サーバーをシャットダウンして実行しますnc -l 8766。これにより、送信されているヘッダーを正確に記録できます。Websocket サーバーを再度オンにし、nc 8766同じヘッダーを貼り付けて結果を確認します。openssl s_client -connect localhost:443それがあなたのミックスにある場合、sslでリクエストを行うことができます。

そこから、応答が websocket ハンドシェイク プロトコルに完全に準拠していることを確認します。たとえば、今の私の問題は、私の応答に が含まれているConnection: closeことです。これは良くありません。

于 2013-03-26T16:34:08.850 に答える
1

http://www.websocket.org echo websocket サーバーから作成した jsfiddle は、Chrome では動作しますが Firefox 6 では動作しません: http://jsfiddle.net/awDLc/

WebSocket ではなく MozWebSocket を使用するように調整されていますが、それでは不十分でしょうか?

于 2011-08-24T22:03:49.533 に答える