2

Internet Explorer 9でSSLを介してクロスドメインフラッシュソケット接続を開始するためにsocket.ioを使用しています。接続を開始すると、クライアントのHTMLWebページ全体を送信するまですべてが正常に機能しているようです。このHTMLを送信しない場合、接続は維持され、接続は少量のデータの送信で機能します。HTMLページ全体を送信すると、socket.ioログに、送信されたHTMLが短くなっていることが示され、その後に。が続きinfo - transport end (undefined)ます。このエラーをさかのぼって追跡しました

if (i === 0){
  if (chr != '\u0000')
    this.error('Bad framing. Expected null byte as first frame');
  else
    continue;
}

default.jsサーバー側のsocket.ioファイルにあります。クライアント側が何らかの理由でこのデータを分割しているようで、これが不正な形式のパケットにつながっています。この量のデータの送信は通常のWebSocketとJSONPで機能するため、TCPエラーになることはありません。

私はこれをデバッグする方法に完全に途方に暮れています。いくつかのコーナーケースのFlash+SSLエラーである可能性があるようです。どんな助けでも大歓迎です。

4

1 に答える 1

2

TL;DR: https://github.com/NextThought/web-socket-jsのファイルを使用して、ローカルの socket.io クライアントの SWF ファイルと web_socket.js を更新してみてください。

長い答え:

socket.io の分散クライアント バージョン (少なくとも 0.9.10 まで) にはバグがあるようです: それが配布する Flash SWF サポート ファイルのバージョン (元々は、上記のリポジトリがフォークされたのと同じ github リポジトリからフォークされたものです) SSL 実装のバグにより、SSL 経由で 16K - 8 バイト (16K は SSL フレーム サイズ、8 バイトは WebSocket ヘッダー サイズ) を超えるサイズの WebSocket フレームを送信できません。これは SSL コードの元のバージョン ( http://code.google.com/p/as3crypto/issues/detail?id=14 ) で特定された問題でしたが、修正はそこにも、どちらにもマージされていません。この記事の執筆時点での github リポジトリの

元の github リポジトリは、最終的な WebSocket 仕様の実装に移行しましたが、socket.io で配布されたバージョンは、はるかに古いドラフト仕様を使用しています (古い仕様にはフレーミング情報があまり含まれていないため、この問題の診断がより困難になります)。 .

最初に参照した github リポジトリには、最新の github の変更と SSL バグ修正を組み込んだ更新された SWF ファイルが含まれています。ローカルの socket.io クライアント ビルドに組み込むのは簡単で、私たちにとっては問題を解決しました (Flash Player 11 を使用した IE9 でのテスト)。接続先の WebSocket サーバーが最終的な WebSocket 仕様をサポートしている場合にのみ機能します。node.js 内で機能させるために、socket.io とともに配布されるフォークの JavaScript 部分に socket.io 固有のパッチがいくつかあります (私はそう思います)。このリポジトリにはこれらのパッチが含まれていないため、おそらく Web ブラウザーでのみ機能します。

于 2012-11-01T15:26:56.737 に答える