WebSocket API HTML5 仕様の翻訳の詳細な紹介

1. はじめに

Webアプリケーションがサーバープロセスとの双方向通信を維持できるようにするために、ここではWebSocketインターフェースを導入します。

2. 一貫性要件(省略)

3. 用語(省略)

4. WebSocketインターフェース(コード省略) WebSocket(url) 、プロトコル)

構築関数

1-2パラメータを渡すことができます。最初の Rigel は、接続先の URL を指定します。 2 番目のパラメーターは、宣言されている場合、string または string array にすることができます。文字列の場合、その文字列のみを含む配列と同等です。 2 番目のパラメーターが省略された場合、空の配列と同等になります (つまり、2 番目のパラメーターに何が渡されたとしても、文字列配列として扱われます)。配列内の各文字列はサブプロトコル名です。接続は、サーバーがいずれかのサブプロトコルを選択したことを宣言した場合にのみ確立できます。すべてのサブプロトコル名は次の要件を満たす必要があります: これらの文字列には、WebSocket プロトコル宣言ヘッダーの Sec-WebSocket-Protocol のコンテンツ ① が含まれている必要があります。 WebSocket()

(1) url

URL のさまざまなコンポーネントを解析して、ホスト、ポート、リソース名、およびセキュリティプロトコル(ホスト、ポート、リソース名、およびセキュア)。このプロセスが失敗した場合、SyntaxError例外がスローされ、以降の手順は終了します。 (2) secure

HTTPSなどのそれ自体がセキュリティプロトコルであるパターンがある場合、SecurityError例外をスローします。 ( secure が false であるが、エントリ スクリプトの オリジンに、それ自体が安全なプロトコル (例: HTTPS) であるスキーム コンポーネントがある場合、SecurityError 例外 をスローします。)

(3) パラメータで使用されるポートがユーザーエージェントによるアクセスを禁止するように設定されている場合、SecurityError例外がスローされます。ポート80と443は、secureがfalse443ポートをブロックできない場合を含め、ブロックすべきではありません。安全ながのとき本当、80ポートへのアクセスは禁止できません [ここでは、WebSocketには2つの形式があり、wsにはセキュリティプロトコルがなく、デフォルトポートがあると言われています80、wssにはセキュリティプロトコルが付属しており、デフォルトで443ポートを使用しますが、使用するプロトコルが対応するポートを必要としない場合でも、443とにアクセスします。 80ポート】を禁止することはできません。 (4)

パラメータ内の変数がこれ以上宣言されている場合、または①の要件を満たしていない場合は、SyntaxError例外をスローして以降の手順を終了します。 (6)

を、ASCII小文字に変換された、エントリスクリプトの起点のASCIIシリアル化にします。(7)新しい

オブジェクトを返し、バックグラウンドプログラムで続行します。以下の手順を参照してください。 (8) 指定された

とプロトコル、空の拡張子(extensions)リストとoriginを含むリストを作成します。 WebSocket接続。正しいcookiesを送信するには、Cookieヘッダーを使用する必要があります。値は、ユーザーが保存したcookie値とurlから計算されます。これらの目的のために、これは HTTP プロトコルのない API ではありません。

「WebSocket接続確立アルゴリズム」の実行中、ユーザーエージェントがサーバーの応答を検証するとき、サーバーから受信したステータスコードが101でない場合、ユーザーエージェントはこれを終了しなければなりません WebSocket 接続します。

警告!ここで HTTP 処理を使用すると、ブラウザーのコンテキストに重大なセキュリティ リスクが発生する可能性があります。たとえば、ホストが 1 つのパス上で WebSocket を使用してセットアップされ、オープンな HTTP リダイレクトが別のパスを指しているサーバーであると想像してください。突然、特定の WebSocket URL で指定されたスクリプトは、URL が正しいホスト名であることをスクリプトがチェックしている場合でも、このサービスに入り、インターネット上の他のホストと通信できるようになります。

注: WebSocket 接続アルゴリズムの実行に失敗すると、WebSocket 接続失敗アルゴリズムがトリガーされ、WebSocket 接続を閉じるアルゴリズムが実行されます。 WebSocket 接続が閉じられ、closeイベントがトリガーされます。実行手順は以下のとおりです。 このコンストラクターは、スクリプトのグローバル オブジェクトが

オブジェクトであるか、WorkerUtils インターフェイスを通じてインスタンス化されたオブジェクトである場合に表示される必要があります。 url

属性 は、コンストラクターに渡された URL から解析する必要があります。 readyState

CONNECTING

0、つまり接続がまだ確立されていないことを意味します。 、対応する値は 1

、これは WebSocket 接続が確立され、通信が実行できることを意味します CLOSING、対応する値は 2

接続が終了ハンドシェイク中であるか、close ()メソッドが呼び出されたことを意味します。対応する値は3で、接続が終了したか、接続できないことを示します。開かれる。

WebSocketのインスタンス化されたオブジェクトが作成されるとき、そのreadyStateの値は

CONNESTINGに設定されなければなりません。

extensions 属性の初期値は空の文字列である必要があります。 WebSocket接続が確立されると、その値は次のルールに従って変更できます。

注: サーバーが拡張機能を選択した場合、extension 属性はサーバーが選択した拡張機能を返します。 (現在、このフィールドは常に空のフィールドです)

プロトコル属性の初期化は空の文字列である必要があります。 WebSocket接続が確立されると、その値は次のルールに従って変更できます。

注: サーバーがサブプロトコルを指定している場合、protocol 属性はサーバーによって選択されたサブプロトコルを返します。

close()メソッドは、次の手順に従って実行する必要があります:

(1) このメソッドが最初のパラメータを渡しても、それが1000と等しくない、または3000ではない場合から 4999以内では、InvalidAccessError例外がスローされ、以降のステップは終了します。

(2) 2 番目のパラメーターが渡された場合は、次のサブステップを実行します:

① 生の理由 をメソッド

の 2 番目のパラメーターにする ② ( は後で を省略)

(3) 以下の最初に一致するステップを実行します

①readyState属性がCLOSINGまたはCLOSEDの場合は何も起こりません。

② WebSocket接続が確立されていない場合は、WebSocket接続の確立を終了し、readyStateの属性値をCLOSINGに設定します。

③ WebSocketのクローズハンドシェイクがまだ開始されていない場合は、WebSocketのクローズハンドシェイクを開始し、readyStateをCLOSINGに設定します。最初のパラメータが渡された場合、メッセージを閉じるために WebSocket によって使用されるステータス コードは、最初のパラメータで指定された integer でなければなりません。 2 番目のパラメーターも宣言されている場合は、終了メッセージのステータス コードの後に​​ reason を指定する必要があります。

④その他の場合は、readyState属性値をCLOSINGに設定します。

以上がWebSocket API HTML5 仕様の翻訳の詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。