WebSockets

WebSocket 接続を得る アルゴリズムは、 所与の ( URL ) に対し： To obtain a WebSocket connection, given a url, run these steps:

1. ホスト :← URL のホスト Let host be url’s host.
2. ポート :← URL のポート Let port be url’s port.
3. リソース名 :← U+002F (/) Let resource name be U+002F (/),＼
4. リソース名 に次の結果を付加する ：URL のパスを U+002F (/) で連結する followed by the strings in url’s path (including empty strings), if any, separated from each other by U+002F (/).
5. IF［ URL のクエリ ≠ 空文字列 ］ ：リソース名 に次を順に付加する ：U+003F (?), URL のクエリ If url’s query is non-empty, append U+003F (?), followed by url’s query, to resource name.
6. セキュアか :← IS［ URL のスキーム ≠ "http" ］ Let secure be false, if url’s scheme is "http"; otherwise true.
7. ［ WebSocket Protocol § クライアントに課される要件 の前半の手続きを成す段 2 〜 5 ］に言明されている要件に従って，WebSocket 接続を確立する [WSP] — 次を与える下で ：( ホスト, ポート, リソース名, セキュアか ) Follow the requirements stated in step 2 to 5, inclusive, of the first set of steps in section 4.1 of The WebSocket Protocol to establish a WebSocket connection, passing host, port, resource name and secure. [WSP]
8. RETURN［ 接続は確立されたなら それ ／ 他の場合は 失敗 ］ If that established a connection, return it, and return failure otherwise.

注記： WebSocket 接続は、 異なるプロパティを運ぶ少し異なる構成なので，共有できないが、 “普通の” 接続にごく近いものである。 Although structured a little differently, carrying different properties, and therefore not shareable, a WebSocket connection is very close to identical to an "ordinary" connection.

WebSocket 接続を確立する アルゴリズムは、 所与の ( URL , プロトコル群, クライアント ) に対し： To establish a WebSocket connection, given a url, protocols, and client, run these steps:

1. 要請 URL :← URL の複製 Let requestURL be a copy of url,＼

2. 要請 URL のスキーム ← URL のスキームに応じて ："ws" ならば "http" ／ 他の場合は "https" with its scheme set to "http", if url’s scheme is "ws"; otherwise to "https".

   注記： このスキームの変更は、 fetch 処理にきちんと統合するために本質的になる。 例えば HSTS は、 こうしないと働かなくなる。 これは、 旧来の遺物である — WebSocket を別個なスキームにする本当の理由はない。 [HSTS] This change of scheme is essential to integrate well with fetching. E.g., HSTS would not work without it. There is no real reason for WebSocket to have distinct schemes, it’s a legacy artefact. [HSTS]

3. 要請 :← 新たな要請 — その ：URL ← 要請 URL , クライアント ← クライアント, service worker モード ← "none", リファラ ← "no-referrer", モード ← "websocket", 資格情報モード ← "include", キャッシュモード ← "no-store", リダイレクトモード ← "error" Let request be a new request, whose URL is requestURL, client is client, service-workers mode is "none", referrer is "no-referrer", mode is "websocket", credentials mode is "include", cache mode is "no-store" , and redirect mode is "error".
4. 要請 のヘッダリストにヘッダを付加する( ( `Upgrade`, `websocket` ) ) Append (`Upgrade`, `websocket`) to request’s header list.
5. 要請 のヘッダリストにヘッダを付加する( ( `Connection`, `Upgrade` ) ) Append (`Connection`, `Upgrade`) to request’s header list.

6. key 値 :← 同型に符号化する( forgiving-base64 符号化する( ランダムに選定された 16 バイトの値 ) ) Let keyValue be a nonce consisting of a randomly selected 16-byte value that has been forgiving-base64-encoded and isomorphic encoded.

   例えば，ランダムに選定された値がバイト列［ 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 ］ならば、 key 値 は，それを forgiving-base64 符号化した結果 "AQIDBAUGBwgJCgsMDQ4PEC==" を同型に符号化した結果 `AQIDBAUGBwgJCgsMDQ4PEC==` になる。 If the randomly selected value was the byte sequence 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, keyValue would be forgiving-base64-encoded to "AQIDBAUGBwgJCgsMDQ4PEC==" and isomorphic encoded to `AQIDBAUGBwgJCgsMDQ4PEC==`.

7. 要請 のヘッダリストにヘッダを付加する( ( `Sec-WebSocket-Key`, key 値 ) ) Append (`Sec-WebSocket-Key`, keyValue) to request’s header list.
8. 要請 のヘッダリストにヘッダを付加する( ( `Sec-WebSocket-Version`, `13` ) ) Append (`Sec-WebSocket-Version`, `13`) to request’s header list.
9. ] プロトコル群 を成す 各( プロトコル ) に対し ：要請 のヘッダリスト内でヘッダを結合する( ( `Sec-WebSocket-Protocol`, プロトコル ) ) For each protocol in protocols, combine (`Sec-WebSocket-Protocol`, protocol) in request’s header list.

10. permessageDeflate :← UA 定義な "permessage-deflate" 拡張ヘッダ値 [WSP] Let permessageDeflate be a user-agent defined "permessage-deflate" extension header value. [WSP]

    `permessage-deflate; client_max_window_bits`
11. 要請 のヘッダリストにヘッダを付加する( ( `Sec-WebSocket-Extensions`, permessageDeflate ) ) Append (`Sec-WebSocket-Extensions`, permessageDeflate) to request’s header list.

12. 要請 を fetch する — 次を与える下で： Fetch request＼

    • 並列キューを利用するか ← true with useParallelQueue set to true,＼

    • 応答の処理 ← 所与の ( 応答 ) に対し，次を走らす手続き： and processResponse given response being these steps:

      1. IF［ 応答 はネットワークエラーである ］∨［ 応答 の状態° ≠ 101 ］ ：WebSocket 接続を失敗させる If response is a network error or its status is not 101, fail the WebSocket connection.

      2. IF［ プロトコル群 は空でない ］∧［ ヘッダリストから値を抽出する( 応答 のヘッダリスト, `Sec-WebSocket-Protocol` ) ∈ { null , 失敗, 空バイト列 } ］ ：WebSocket 接続を失敗させる If protocols is not the empty list and extracting header list values given `Sec-WebSocket-Protocol` and response’s header list results in null, failure, or the empty byte sequence, then fail the WebSocket connection.

         注記： これは、［ WebSocket Protocol にて定義される，このヘッダに対する検査 ］と異なる。 そこでは、［ クライアントから要請されていない下位プロトコルがある場合 ］しか受け持ってなかった。 ここでは、［ クライアントから要請された下位プロトコルがサーバから承認されていない場合 ］も受け持つ。 This is different from the check on this header defined by The WebSocket Protocol. That only covers a subprotocol not requested by the client. This covers a subprotocol requested by the client, but not acknowledged by the server.

      3. ［ WebSocket Protocol § クライアントに課される要件 の後半の手続きを成す段 2 〜 6 ］に言明されている要件に従って， 応答 を検証する — これは、 WebSocket 接続を［ 失敗させるか確立させる ］ことになる。 Follow the requirements stated step 2 to step 6, inclusive, of the last set of steps in section 4.1 of The WebSocket Protocol to validate response. This either results in fail the WebSocket connection or the WebSocket connection is established.

new WebSocket(url, protocols) 構築子手続きは： The new WebSocket(url, protocols) constructor steps are:

1. 基底 URL :← これ°に関連する設定群オブジェクトの API 用基底 URL Let baseURL be this's relevant settings object's API base URL.
2. URL レコード :← URL 構文解析する( url, 基底 URL ) Let urlRecord be the result of applying the URL parser to url with baseURL.
3. IF［ URL レコード ＝ 失敗 ］ ：THROW SyntaxError If urlRecord is failure, then throw a "SyntaxError" DOMException.
4. IF［ URL レコード のスキーム ＝ "http" ］ ：URL レコード のスキーム ← "ws" If urlRecord’s scheme is "http", then set urlRecord’s scheme to "ws".
5. ELSE IF［ URL レコード のスキーム ＝ "https" ］ ：URL レコード のスキーム ← "wss" Otherwise, if urlRecord’s scheme is "https", set urlRecord’s scheme to "wss".
6. IF［ URL レコード のスキーム ∉ { "ws", "wss" } ］ ：THROW SyntaxError If urlRecord’s scheme is not "ws" or "wss", then throw a "SyntaxError" DOMException.
7. IF［ URL レコード の素片 ≠ null ］ ：THROW SyntaxError If urlRecord’s fragment is non-null, then throw a "SyntaxError" DOMException.
8. プロトコル群 :← protocols に応じて ：文字列であるならば « protocols » 他の場合は protocols If protocols is a string, set protocols to a sequence consisting of just that string.
9. IF［ プロトコル群 内に重複する値がある ］∨［ プロトコル群 内の値に［［ [WSP] に定義される `Sec-WebSocket-Protocol` フィールド ］の値を成す各プロトコル要素に課される要件 ］を満たさないものがある ］ ：THROW SyntaxError If any of the values in protocols occur more than once or otherwise fail to match the requirements for elements that comprise the value of `Sec-WebSocket-Protocol` fields as defined by The WebSocket protocol, then throw a "SyntaxError" DOMException. [WSP]
10. これ°の URL ← URL レコード Set this's url to urlRecord.
11. クライアント :← これ°に関連する設定群オブジェクト Let client be this's relevant settings object.

12. この段は並列的に走らす ：WebSocket 接続を確立する( URL レコード, プロトコル群, クライアント ) [FETCH] Run this step in parallel: • Establish a WebSocket connection given urlRecord, protocols, and client. [FETCH]

    注記： WebSocket 接続を確立するのに失敗した場合 ：それにより，WebSocket 接続を失敗させるアルゴリズムが誘発され ：それにより，WebSocket 接続を close するアルゴリズムが呼び出され ：それにより，WebSocket 接続は close 済みになり ：それに伴い，後述のように close イベントが発火されることになる。 If the establish a WebSocket connection algorithm fails, it triggers the fail the WebSocket connection algorithm, which then invokes the close the WebSocket connection algorithm, which then establishes that the WebSocket connection is closed, which fires the close event as described below.

close(code, reason) メソッド手続きは： The close(code, reason) method steps are:

1. IF［ code ≠ ε ］∧［ code ∉ { 1000, 3000 ～ 4999 } ］ ：THROW InvalidAccessError If code is present, but is neither an integer equal to 1000 nor an integer in the range 3000 to 4999, inclusive, throw an "InvalidAccessError" DOMException.

2. IF［ reason ≠ ε ］： If reason is present, then run these substeps:

   1. 事由バイト列 ← UTF-8 符号化する( reason ) Let reasonBytes be the result of encoding reason.
   2. IF［ 事由バイト列 を成すバイト数 > 123 ］ ：THROW SyntaxError If reasonBytes is longer than 123 bytes, then throw a "SyntaxError" DOMException.

3. IF［ これ°の準備状態 ∈ { CLOSING, CLOSED } ］ ：RETURN Run the first matching steps from the following list:If this's ready state is CLOSING (2) or CLOSED (3) • Do nothing.

   注記： 接続は、 close しつつあるか, すでに close 済みである。 close 済みでない場合、 最終的には，後述のように close イベントが発火されることになる。 The connection is already closing or is already closed. If it has not already, a close event will eventually fire as described below.

4. ELSE IF［ WebSocket 接続は確立済みでない [WSP] ］ ：WebSocket 接続を失敗させる； これ°の準備状態 ← CLOSING If the WebSocket connection is not yet established [WSP] • Fail the WebSocket connection and set this's ready state to CLOSING (2). [WSP]

   注記： WebSocket 接続を失敗させるアルゴリズムは ：WebSocket 接続を close するアルゴリズムを呼び出す ：それにより，WebSocket 接続は close 済みになる ：それに伴い，後述のように close イベントが発火されることになる。 The fail the WebSocket connection algorithm invokes the close the WebSocket connection algorithm, which then establishes that the WebSocket connection is closed, which fires the close event as described below.

5. ELSE IF［ WebSocket closing ハンドシェイクは開始済みでない ］： If the WebSocket closing handshake has not yet been started [WSP]

   1. WebSocket closing ハンドシェイクを開始する： Start the WebSocket closing handshake＼ ↓and set this's ready state to CLOSING (2). [WSP]

      • ［ code ＝ ε ］∧［ reason ＝ ε ］ならば ：Close メッセージは，ボディを持たないものとする。 If neither code nor reason is present, the WebSocket Close message must not have a body.

        注記： [WSP] は、［ WebSocket closing ハンドシェイクを開始するアルゴリズムに状態°コードが要求される ］ものと，誤って言明している。 The WebSocket Protocol erroneously states that the status code is required for the start the WebSocket closing handshake algorithm.

      • ［ code ≠ ε ］ならば ：Close メッセージに利用する状態°コードは、 code に与えられた整数にするものとする。 If code is present, then the status code to use in the WebSocket Close message must be the integer given by code. [WSP]
      • ［ code ≠ ε ］∧［ reason ≠ ε ］ならば ：Close メッセージには，状態°コードに加えて reason も供するものとする。 If reason is also present, then reasonBytes must be provided in the Close message after the status code. [WSP]

   2. これ°の準備状態 ← CLOSING ↑

   注記： WebSocket closing ハンドシェイクを開始するアルゴリズムは ：最終的には WebSocket 接続を close するアルゴリズムを呼び出すことになる ：それにより，WebSocket 接続は close 済みになる ：それに伴い，後述のように close イベントが発火されることになる。 The start the WebSocket closing handshake algorithm eventually invokes the close the WebSocket connection algorithm, which then establishes that the WebSocket connection is closed, which fires the close event as described below.

6. ELSE ：これ°の準備状態 ← CLOSING Otherwise • Set this's ready state to CLOSING (2).

   注記： WebSocket closing ハンドシェイクは開始済みであり ：最終的には WebSocket 接続を close するアルゴリズムを呼び出すことになる ：それにより，WebSocket 接続は close 済みになる ：それに伴い，後述のように close イベントが発火されることになる。 The WebSocket closing handshake is started, and will eventually invoke the close the WebSocket connection algorithm, which will establish that the WebSocket connection is closed, and thus the close event will fire, as described below.

注記： close() メソッドは、［ WebSocket closing ハンドシェイクを開始する以前に送信したメッセージ ］を破棄するものではない — 仮に，UA がそのようなメッセージをまだ送信中であったとしても、 ハンドシェイクが開始されるのは，そのメッセージを送信した後に限られることになる。 The close() method does not discard previously sent messages before starting the WebSocket closing handshake — even if, in practice, the user agent is still busy sending those messages, the handshake will only start after the messages are sent.

bufferedAmount 取得子手続きは、 アプリデータ（UTF-8 テキストデータ, またはバイナリデータ） — send() によりキューされたが、 イベントループがその最初の段に最後に達した時点では，ネットワークにまだ伝送されていないそれ — のバイト数を返す。 （したがって、 これは，現在のタスクの実行中に伝送されたテキストを含む — UA が［ スクリプト実行と並列的に，背後でテキストを伝送できるかどうか ］にかかわらず）。 これには、［ プロトコルから課されるフレーム法のオーバーヘッド／ OS やネットワークハードウェアによるバッファ処理 ］は含まれない。 The bufferedAmount getter steps are to return the number of bytes of application data (UTF-8 text and binary data) that have been queued using send() but that, as of the last time the event loop reached step 1, had not yet been transmitted to the network. (This thus includes any text sent during the execution of the current task, regardless of whether the user agent is able to transmit text in the background in parallel with script execution.) This does not include framing overhead incurred by the protocol, or buffering done by the operating system or network hardware.

send(data) そのメソッド手続きは： The send(data) method steps are:

1. IF［ これ°の準備状態 ＝ CONNECTING ］ ：THROW InvalidStateError If this's ready state is CONNECTING, then throw an "InvalidStateError" DOMException.

2. IF［ WebSocket 接続は確立済みである ］∧［ WebSocket closing ハンドシェイクは開始済みでない 【すなわち，準備状態 ＝ OPEN 】 ］ ：data 引数の型に応じて，下の表に与えられる［ opcode , およびペイロードデータ ］から構成される WebSocket メッセージを送信する ：バッファを要する所でバッファが満杯になっているなどの理由で，データを送信できない場合 ：この接続の満杯かを true にした上で，WebSocket 接続を close する

   引数の型	opcode	ペイロードデータ
   DOMString	テキストフレーム（数値 1 ）	UTF-8 符号化する( data ) の結果。 [UNICODE] [ENCODING]
   Blob	バイナリフレーム（数値 2 ）	data が表現する生データ。 [FILEAPI]
   ArrayBuffer		data が表現するバッファに格納されているデータ。
   ArrayBufferView		data が参照している，下層の ArrayBuffer オブジェクトが格納するバッファの中の一区分。

   【 ここの訳は、 原文の同じ文言の繰り返しを集約して再構成している。 】

   Run the appropriate set of steps from the following list:If data is a string • If the WebSocket connection is established and the WebSocket closing handshake has not yet started, then the user agent must send a WebSocket Message comprised of the data argument using a text frame opcode; if the data cannot be sent, e.g. because it would need to be buffered but the buffer is full, the user agent must flag the WebSocket as full and then close the WebSocket connection. Any invocation of this method with a string argument that does not throw an exception must increase the bufferedAmount attribute by the number of bytes needed to express the argument as UTF-8. [UNICODE] [ENCODING] [WSP]If data is a Blob object • If the WebSocket connection is established, and the WebSocket closing handshake has not yet started, then the user agent must send a WebSocket Message comprised of data using a binary frame opcode; if the data cannot be sent, e.g. because it would need to be buffered but the buffer is full, the user agent must flag the WebSocket as full and then close the WebSocket connection. The data to be sent is the raw data represented by the Blob object. Any invocation of this method with a Blob argument that does not throw an exception must increase the bufferedAmount attribute by the size of the Blob object’s raw data, in bytes. [WSP] [FILEAPI]If data is an ArrayBuffer • If the WebSocket connection is established, and the WebSocket closing handshake has not yet started, then the user agent must send a WebSocket Message comprised of data using a binary frame opcode; if the data cannot be sent, e.g. because it would need to be buffered but the buffer is full, the user agent must flag the WebSocket as full and then close the WebSocket connection. The data to be sent is the data stored in the buffer described by the ArrayBuffer object. Any invocation of this method with an ArrayBuffer argument that does not throw an exception must increase the bufferedAmount attribute by the length of the ArrayBuffer in bytes. [WSP]If data is an ArrayBufferView • If the WebSocket connection is established, and the WebSocket closing handshake has not yet started, then the user agent must send a WebSocket Message comprised of data using a binary frame opcode; if the data cannot be sent, e.g. because it would need to be buffered but the buffer is full, the user agent must flag the WebSocket as full and then close the WebSocket connection. The data to be sent is the data stored in the section of the buffer described by the ArrayBuffer object that data references. Any invocation of this method with this kind of argument that does not throw an exception must increase the bufferedAmount attribute by the length of data’s buffer in bytes. [WSP]
3. bufferedAmount 属性の値 += 前段によるペイロードデータに要するバイト数 ↑