WebSockets （日本語訳）

◎要約

この仕様は、［ ~web~appが~server側~processとの双方向-通信を保守する］ことを可能化するための~APIを供する。 ◎ This specification provides APIs to enable web applications to maintain bidirectional communications with server-side processes.

【この~pageは，以前は［ ~HTML仕様の一部を成す § Web sockets の和訳］を与えていたが、［その節（および， `Fetch^cite 内の~WebSocketに関連な節）が独立な仕様として，この標準に分離された］ことに伴い，その内容の和訳に置換したものである。】

1. 序論

◎非規範的

［ ~web~appが~server側~processとの双方向-通信を保守する］ことを可能化するため、この仕様は， `WebSocket$I ~interfaceを導入する。 ◎ To enable web applications to maintain bidirectional communications with server-side processes, this specification introduces the WebSocket interface.

注記：この~interfaceは、下層の~networkへの生の~accessを許容するものではない。例えば，~custom~serverを介した~messageの~proxy法を利用しない限り、この~interfaceを IRC ~clientの実装に利用することはできない。 ◎ This interface does not allow for raw access to the underlying network. For example, this interface could not be used to implement an IRC client without proxying messages through a custom server.

【この訳に特有な表記規約】

◎表記記号

以下に挙げる用語は、 ~WebSocket~protocol仕様 `WSP$r にて定義される（この訳では、日本語訳への~linkを “参照” として与える — これらは、原文では， `URL Fragment Text Directives^cite に定義される`素片~指令＠https://wicg.github.io/scroll-to-text-fragment/#fragmentdirective#fragment-directive$を伴う~URLとして与えられている）：

`状態s~code@ws （ ~HTTP応答の`状態s~code＠~HTTPsem#status-code$ではないことに注意）
`~WebSocket接続は確立-済み@ws
`~WebSocket接続を失敗させる@ws
`~WebSocket~closing~handshakeを開始する@ws
`~WebSocket~closing~handshakeは開始-済み@ws
`~WebSocket~messageを送信する@ws
`~WebSocket~messageを受信した@ws
`~WebSocket接続を~closeする@ws
`~WebSocket接続は~close済み@ws
`~cleanに~closeされた@ws
`~WebSocket接続~close~code@ws
`~WebSocket接続~close事由@ws
`下位protocol@ws
`下位protocol名@ws
`利用-中にある下位protocol@ws
`利用-中にある拡張@ws
`Close ~frame@ws
`Ping ~frame@ws
`Pong ~frame@ws
`~opcode@ws
`~payload~data@ws

2. ~WebSocket~protocolの改め

注記：この節は、［ ~WebSocket~protocolの~opening~handshakeに課される~client要件］の一部を［ `Fetch^cite にて定義される~algoに統合する］ために置換する。 `Fetch^cite に関係する~protocol — ~CSP, ~cookie, ~HSTS など — は、この仕方で，一箇所に集約して取扱われるようになる。 ~RFCがこの文言で更新されるのが理想だが、それは決して容易にはならない。以下に定義される `WebSocket$I ~APIは、この文言を利用する。 `WSP$r `FETCH$r ◎ This section replaces part of the WebSocket protocol opening handshake client requirement to integrate it with algorithms defined in Fetch. This way CSP, cookies, HSTS, and other Fetch-related protocols are handled in a single location. Ideally the RFC would be updated with this language, but it is never that easy. The WebSocket API, defined below, uses this language. [WSP] [FETCH]

これは、［ `WebSocket Protocol^cite の “~WebSocket接続を確立する” ~algo ］を［新たなものに置換して， `Fetch^cite に統合する］ような仕方で働く — “~WebSocket接続を確立する” は、 3 つの~algo［接続を設定しておく, ~handshake要請を作成して伝送する, ~handshake応答を検証する］からなる。その重ね方は、 `Fetch^cite による［先ず~handshakeを作成して，次に接続を設定しておいてから、 ~handshakeを伝送して，~~最後に応答を検証する］のとは異なる。この改めを読むときは、そのことを念頭に置くこと。 ◎ The way this works is by replacing The WebSocket Protocol’s "establish a WebSocket connection" algorithm with a new one that integrates with Fetch. "Establish a WebSocket connection" consists of three algorithms: setting up a connection, creating and transmiting a handshake request, and validating the handshake response. That layering is different from Fetch, which first creates a handshake, then sets up a connection and transmits the handshake, and finally validates the response. Keep that in mind while reading these alterations.

2.1. 接続

`~WebSocket接続を得する@ ときは、所与の ( %~URL ) に対し，次の手続きを走らす： ◎ To obtain a WebSocket connection, given a url, run these steps:

%~host ~LET %~URL の`~host$url ◎ Let host be url’s host.
%~port ~LET %~URL の`~port$url ◎ Let port be url’s port.
%資源~名 ~LET `002F^U (/) ◎ Let resource name be U+002F (/),＼
%資源~名に次の結果を付加する ⇒ %~URL の`~path$urlを `002F^U (/) で`連結する$ ◎ followed by the strings in url’s path (including empty strings), if any, separated from each other by U+002F (/).
~IF［ %~URL の`~query$url ~NEQ 空~文字列］ ⇒ %資源~名に次を順に付加する ⇒＃ `003F^U (?), %~URL の`~query$url ◎ If url’s query is non-empty, append U+003F (?), followed by url’s query, to resource name.
%~secureか ~LET ~IS［ %~URL の`~scheme$url ~NEQ `http^l ］ ◎ Let secure be false, if url’s scheme is "http"; otherwise true.
［ `WebSocket Protocol^cite `§ ~clientに課される要件＠~RFC6455#section-4.1$ の`前半の手続き＠~RFC6455#dfn-to-establish$を成す段 2 〜 5 ］に言明されている要件に従って，~WebSocket接続を確立する `WSP$r — 次を与える下で ⇒ ( %~host, %~port, %資源~名, %~secureか ) ◎ 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]
~RET［接続は確立されたならそれ／ ~ELSE_ `失敗^i ］ ◎ If that established a connection, return it, and return failure otherwise.

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

2.2. ~opening~handshake

`~WebSocket接続を確立する@ ときは、所与の ( %~URL, %~protocol群, %~client ) に対し，次の手続きを走らす： ◎ To establish a WebSocket connection, given a url, protocols, and client, run these steps:

%要請~URL ~LET %~URL の複製 ◎ Let requestURL be a copy of url,＼
%要請~URL の`~scheme$url ~SET %~URL の`~scheme$urlに応じて ⇒＃ `ws^l ならば `http^l ／ ~ELSE_ `https^l ◎ with its scheme set to "http", if url’s scheme is "ws"; otherwise to "https".

注記：この~schemeの変更は、 `~fetching$にきちんと統合するために本質的になる。例えば~HSTSは、こうしないと働かなくなる。これは、旧来の遺物である — ~WebSocketを別個な~schemeにする本当の理由はない。 `HSTS$r ◎ 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]
%要請 ~LET 新たな`要請$ — その ⇒＃ `~URL$rq ~SET %要請~URL, `~client$rq ~SET %~client, `~sw~mode$rq ~SET `none^l, `~referrer$rq ~SET `no-referrer^l, `~mode$rq ~SET `websocket^l, `資格証~mode$rq ~SET `include^l, `~cache~mode$rq ~SET `no-store^l, `~redirect~mode$rq ~SET `error^l ◎ 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".
%要請の`~header~list$rqに`~headerを付加する$( ( `Upgrade$h, `websocket^bl ) ) ◎ Append (`Upgrade`, `websocket`) to request’s header list.
%要請の`~header~list$rqに`~headerを付加する$( ( `Connection$h, `Upgrade^bl ) ) ◎ Append (`Connection`, `Upgrade`) to request’s header list.
%~key値 ~LET `同型に符号化する$( `~forgiving-base64符号化する$( ~randomに選定された 16 ~byteの値 ) ) ◎ Let keyValue be a nonce consisting of a randomly selected 16-byte value that has been forgiving-base64-encoded and isomorphic encoded.

例えば，~randomに選定された値が~byte列［ `01^X `02^X `03^X `04^X `05^X `06^X `07^X `08^X `09^X `0a^X `0b^X `0c^X `0d^X `0e^X `0f^X `10^X ］ならば、 %~key値は，それを~forgiving-base64符号化した結果 `AQIDBAUGBwgJCgsMDQ4PEC==^l を同型に符号化した結果 `AQIDBAUGBwgJCgsMDQ4PEC==^bl になる。 ◎ 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==`.
%要請の`~header~list$rqに`~headerを付加する$( ( `Sec-WebSocket-Key$h, %~key値 ) ) ◎ Append (`Sec-WebSocket-Key`, keyValue) to request’s header list.
%要請の`~header~list$rqに`~headerを付加する$( ( `Sec-WebSocket-Version$h, `13^bl ) ) ◎ Append (`Sec-WebSocket-Version`, `13`) to request’s header list.
] %~protocol群を成す ~EACH( %~protocol ) に対し ⇒ %要請の`~header~list$rq内で`~headerを結合する$( ( `Sec-WebSocket-Protocol$h, %~protocol ) ) ◎ For each protocol in protocols, combine (`Sec-WebSocket-Protocol`, protocol) in request’s header list.
%permessageDeflate ~LET ~UA定義な `permessage-deflate^l 拡張`~header値$ `WSP$r ◎ Let permessageDeflate be a user-agent defined "permessage-deflate" extension header value. [WSP]

`permessage-deflate; client_max_window_bits^bl
%要請の`~header~list$rqに`~headerを付加する$( ( `Sec-WebSocket-Extensions$h, %permessageDeflate ) ) ◎ Append (`Sec-WebSocket-Extensions`, permessageDeflate) to request’s header list.
%要請を`~fetchする$ — 次を与える下で： ◎ Fetch request＼
- `並列~queueを利用するか$i ~SET ~T ◎ with useParallelQueue set to true,＼
- `応答の処理n$i ~SET 所与の ( %応答 ) に対し，次を走らす手続き： ◎ and processResponse given response being these steps:
  1. ~IF［ %応答は`~network~error$である］~OR［ %応答の`状態s$rs ~NEQ `101$st ］ ⇒ `~WebSocket接続を失敗させる$ws ◎ If response is a network error or its status is not 101, fail the WebSocket connection.
  2. ~IF［ %~protocol群は空でない］~AND［ `~header~listから値を抽出する$( %応答の`~header~list$rs, `Sec-WebSocket-Protocol$h ) ~IN { ~NULL, `失敗^i, 空~byte列 } ］ ⇒ `~WebSocket接続を失敗させる$ws ◎ 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^cite にて定義される，この~headerに対する検査］と異なる。そこでは、［ ~clientから要請されていない下位protocolがある場合］しか受持ってなかった。ここでは、［ ~clientから要請された下位protocolが~serverから承認されていない場合］も受持つ。 ◎ 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^cite `§ ~clientに課される要件＠~RFC6455#section-4.1$ の後半の手続きを成す段 2 〜 6 ］に言明されている要件に従って， %応答を検証する — これは、~WebSocket接続を［ `失敗-$wsさせるか`確立-$wsさせる］ことになる。 ◎ 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.

◎ ↑↑Fail the WebSocket connection and the WebSocket connection is established are defined by The WebSocket Protocol. [WSP]

警告： ~redirectに追従しない理由は、 ~web~browser文脈に深刻な~security問題を導入するからである。そのため、この~handshakeは，一般に制約される。例えば、ある~hostが，ある~pathに~WebSocket~serverを立てていたとする。当の~hostが，別の~pathにも~openな~HTTP~redirect器【`参考＠https://wiki.suikawiki.org/n/open%20redirector$】を立てた時点で、 ~WebSocket~URLを与え得るようなどの~scriptも — 当の~URLの~hostnameが的確であることを検査したとしても — ~internet上の~~任意の~hostと通信する（したがって秘匿情報を共有し得る）よう騙すことが可能になる。【！ https://www.ietf.org/mail-archive/web/hybi/current/msg06951.html】 ◎ The reason redirects are not followed and this handshake is generally restricted is because it could introduce serious security problems in a web browser context. For example, consider a host with a WebSocket server at one path and an open HTTP redirector at another. Suddenly, any script that can be given a particular WebSocket URL can be tricked into communicating to (and potentially sharing secrets with) any host on the internet, even if the script checks that the URL has the right hostname.

3. `WebSocket^I ~interface

3.1. ~interface定義

`WebSocket$I ~class用の~Web~IDL定義は、次で与えられる： ◎ The Web IDL definition for the WebSocket class is given as follows:

enum `BinaryType@I { `blob$l, `arraybuffer$l };

[`Exposed$=(Window,Worker)]
interface `WebSocket@I : `EventTarget$I {
  `constructor＠#dom-websocket-websocket$(`USVString$ %url, optional (`DOMString$ or `sequence$<`DOMString$>) %protocols = []);
  readonly attribute `USVString$ `url$m;

  // ready state
  const `unsigned short$ `CONNECTING$m = 0;
  const `unsigned short$ `OPEN$m = 1;
  const `unsigned short$ `CLOSING$m = 2;
  const `unsigned short$ `CLOSED$m = 3;
  readonly attribute `unsigned short$ `readyState$m;
  readonly attribute `unsigned long long$ `bufferedAmount$m;

  // networking
  attribute `EventHandler$I `onopen$m;
  attribute `EventHandler$I `onerror$m;
  attribute `EventHandler$I `onclose$m;
  readonly attribute `DOMString$ `extensions$m;
  readonly attribute `DOMString$ `protocol$m;
  `undefined$ `close$m(optional [`Clamp$] `unsigned short$ %code, optional `USVString$ %reason);

  // messaging
  attribute `EventHandler$I `onmessage$m;
  attribute `BinaryType$I `binaryType$m;
  `undefined$ `send$m((`BufferSource$I or `Blob$I or `USVString$) %data);
};

各 `WebSocket$I ~objには、次に挙げるものが結付けられる： ◎ ↓

`~URL@wS ◎ Each WebSocket object has an associated url,＼

`~URL~record$。【構築-時に設定される。】 ◎ which is a URL record.

`~binary種別@wS （ `binary type^en ） ◎ Each WebSocket object has an associated binary type,＼

`BinaryType$I 値 — 初期~時は `blob$l になるモノトスル。 ◎ which is a BinaryType. Initially it must be "blob".

`準備y状態@wS （ `ready state^en ） ◎ Each WebSocket object has an associated ready state,＼

当の接続の状態を表現している数値 — 初期~時は `CONNECTING$m になるモノトスル。 ◎ which is a number representing the state of the connection. Initially it must be CONNECTING (0).＼

次に挙げる値をとり得る： ◎ It can have the following values:

`CONNECTING@m （数値 0 ） ⇒ `~WebSocket接続は確立-済み$wsでない。 ◎ CONNECTING (numeric value 0) • The connection has not yet been established.
`OPEN@m （数値 1 ） ⇒ `~WebSocket接続は確立-済み$wsであり，通信は可能である。 ◎ OPEN (numeric value 1) • The WebSocket connection is established and communication is possible.
`CLOSING@m （数値 2 ） ⇒ 接続は~handshakeの~close中にあるか，または `close()$m ~methodが呼出されている。 ◎ CLOSING (numeric value 2) • The connection is going through the closing handshake, or the close() method has been invoked.
`CLOSED@m （数値 3 ） ⇒ 接続はすでに`~closeされ$wsたか，または~openできなかった。 ◎ CLOSED (numeric value 3) • The connection has been closed or could not be opened.

%socket = `new WebSocket(url [, protocols ])$m

新たな `WebSocket$I ~objを作成した上で、それに結付けられる~WebSocket接続を即時に確立する。 ◎ Creates a new WebSocket object, immediately establishing the associated WebSocket connection.

%url は文字列をとり、それが与える`~URL~record$に向けて，接続が確立される。許容される~schemeは［ `ws^l, `wss^l, `http^l, `https^l ］いずれかに限られ、他に対しては `SyntaxError$E が投出される。 ~URLに`素片$urlが伴われる場合も常にそれが投出される。 ◎ url is a string giving the URL over which the connection is established. Only "ws", "wss", "http", and "https" schemes are allowed; others will cause a "SyntaxError" DOMException. URLs with fragments will always cause such an exception.

省略可能な %protocols は、［文字列, または文字列たちが成す配列］をとり，［省略-時は空な配列／文字列ならば，その文字列のみからなる配列］と等価になる。配列~内の各文字列は`下位protocol名$wsを表す。接続が`確立-$wsされるのは、 ~serverが，これらの`下位protocol$wsの一つを応答に選定して返したときに限られることになる。どの下位protocol名も、［ `WSP$r に定義される `Sec-WebSocket-Protocol$h ~field ］の値を成す各~protocol要素に課される要件に合致する必要がある。 ◎ protocols is either a string or an array of strings. If it is a string, it is equivalent to an array consisting of just that string; if it is omitted, it is equivalent to the empty array. Each string in the array is a subprotocol name. The connection will only be established if the server reports that it has selected one of these subprotocols. The subprotocol names have to match the requirements for elements that comprise the value of `Sec-WebSocket-Protocol` fields as defined by The WebSocket protocol. [WSP]

%socket.`send(data)$m

~WebSocket接続を利用して %data を伝送する。 %data は［文字列, `Blob$I, `ArrayBuffer$I, `ArrayBufferView$I ］のいずれかをとり得る。 ◎ Transmits data using the WebSocket connection. data can be a string, a Blob, an ArrayBuffer, or an ArrayBufferView.

%socket.`close([ code ] [, reason ])$m

~WebSocket接続を~closeする。 %code は`~WebSocket接続~close~code$wsとして， %reason は`~WebSocket接続~close事由$wsとして利用される（いずれも省略可）。 ◎ Closes the WebSocket connection, optionally using code as the WebSocket connection close code and reason as the WebSocket connection close reason.

%socket.`url$m

~WebSocket接続を確立するときに利用された`~URL$を返す。 ◎ Returns the URL that was used to establish the WebSocket connection.

%socket.`readyState$m

当の~WebSocket接続の状態を返す。上に述べた値をとり得る。 ◎ Returns the state of the WebSocket connection. It can have the values described above.

%socket.`bufferedAmount$m

`send()$m を利用して~queueされたが, まだ ~networkに伝送されていない，~app~data（~UTF-8~text／~binary~data）を成す~byte数を返す。 ◎ Returns the number of bytes of application data (UTF-8 text and binary data) that have been queued using send() but not yet been transmitted to the network.

~WebSocket接続が`~closeされ$wsた場合、この属性の値は， `send()$m ~methodが~callされる度に増えることになる（この数値は、接続が`~closeされ$wsても， 0 に設定し直されることはない）。 ◎ If the WebSocket connection is closed, this attribute’s value will only increase with each call to the send() method. (The number does not reset to zero once the connection closes.)

%socket.`extensions$m

~serverにより選定された拡張があれば，それを返す。 ◎ Returns the extensions selected by the server, if any.

%socket.`protocol$m

~serverにより選定された`下位protocol$wsがあれば，それを返す。これは、下位protocolの折衝を遂行するために，構築子の（配列~形にされた） 2 個目の引数と併用され得る。 ◎ Returns the subprotocol selected by the server, if any. It can be used in conjunction with the array form of the constructor’s second argument to perform subprotocol negotiation.

%socket.`binaryType$m

~socketからの~binary~dataが~scriptにどう公開されるかを指示する文字列を返す： ◎ Returns a string that indicates how binary data from socket is exposed to scripts:

`blob$l: ~binary~dataは `Blob$I 形で返された。 ◎ Binary data is returned in Blob form.
`arraybuffer$l: ~binary~dataは `ArrayBuffer$I 形で返された。 ◎ Binary data is returned in ArrayBuffer form.

既定では `blob$l になる。 ◎ The default is "blob".

%socket.`binaryType$m = %value

~binary~dataがどう返されるかを変更する。 ◎ Changes how binary data is returned.

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

%基底~URL ~LET コレに`関連な設定群~obj$の`~API用~基底~URL$enV ◎ Let baseURL be this's relevant settings object's API base URL.
%~URL~record ~LET `~URL構文解析する$( %url, %基底~URL ) ◎ Let urlRecord be the result of applying the URL parser to url with baseURL.
~IF［ %~URL~record ~EQ `失敗^i ］ ⇒ ~THROW `SyntaxError$E ◎ If urlRecord is failure, then throw a "SyntaxError" DOMException.
~IF［ %~URL~record の`~scheme$url ~EQ "`http^sc" ］ ⇒ %~URL~record の`~scheme$url ~SET "`ws$sc" ◎ If urlRecord’s scheme is "http", then set urlRecord’s scheme to "ws".
~ELIF［ %~URL~record の`~scheme$url ~EQ "`https^sc" ］ ⇒ %~URL~record の`~scheme$url ~SET "`wss$sc" ◎ Otherwise, if urlRecord’s scheme is "https", set urlRecord’s scheme to "wss".
~IF［ %~URL~record の`~scheme$url ~NIN { "`ws$sc", "`wss$sc" } ］ ⇒ ~THROW `SyntaxError$E ◎ If urlRecord’s scheme is not "ws" or "wss", then throw a "SyntaxError" DOMException.
~IF［ %~URL~record の`素片$url ~NEQ ~NULL ］ ⇒ ~THROW `SyntaxError$E ◎ If urlRecord’s fragment is non-null, then throw a "SyntaxError" DOMException.
%~protocol群 ~LET %protocols に応じて ⇒＃文字列であるならば « %protocols » ~ELSE_ %protocols ◎ If protocols is a string, set protocols to a sequence consisting of just that string.
~IF［ %~protocol群内に重複する値がある］~OR［ %~protocol群内の値に［［ `WSP$r に定義される `Sec-WebSocket-Protocol$h ~field ］の値を成す各~protocol要素に課される要件］を満たさないものがある］ ⇒ ~THROW `SyntaxError$E ◎ 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]
コレの`~URL$wS ~SET %~URL~record ◎ Set this's url to urlRecord.
%~client ~LET コレに`関連な設定群~obj$ ◎ Let client be this's relevant settings object.
この段は`並列的$に走らす ⇒ `~WebSocket接続を確立する$( %~URL~record, %~protocol群, %~client ) `FETCH$r ◎ Run this step in parallel: • Establish a WebSocket connection given urlRecord, protocols, and client. [FETCH]

注記： `~WebSocket接続を確立する$のに失敗した場合 ⇒ それにより，`~WebSocket接続を失敗させる$ws~algoが誘発され ⇒ それにより，`~WebSocket接続を~closeする$ws~algoが呼出され ⇒ それにより，`~WebSocket接続は~close済み$wsになり ⇒ それに伴い，`後述のように$ `close$et ~eventが発火されることになる。 ◎ 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.

`url@m 取得子~手続きは ⇒ ~RET `~URLを直列化する$( コレの`~URL$wS ) ◎ The url getter steps are to return this's url, serialized.

`readyState@m 取得子~手続きは ⇒ ~RET コレの`準備y状態$wS ◎ The readyState getter steps are to return this's ready state.

`extensions@m 属性は、初期~時には空~文字列を返すモノトスル。その値は、 ~WebSocket接続が`確立-$wsされた後に， `§ ~protocolからの~feedback＠#feedback-from-the-protocol$ にて定義されるとおり変更され得る。 ◎ The extensions attribute must initially return the empty string. After the WebSocket connection is established, its value might change, as defined below.

`protocol@m 属性は、初期~時には空~文字列を返すモノトスル。その値は、 ~WebSocket接続が`確立-$wsされた後に， `§ ~protocolからの~feedback＠#feedback-from-the-protocol$ にて定義されるとおり変更され得る。 ◎ The protocol attribute must initially return the empty string. After the WebSocket connection is established, its value might change, as defined below.

`close(code, reason)@m ~method手続きは： ◎ The close(code, reason) method steps are:

~IF［ %code ~NEQ ε ］~AND［ %code ~NIN { 1000, 3000 ～ 4999 } ］ ⇒ ~THROW `InvalidAccessError^E ◎ 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.
~IF［ %reason ~NEQ ε ］： ◎ If reason is present, then run these substeps:
1. %事由~byte列 ~SET `~UTF-8符号化する$( %reason ) ◎ Let reasonBytes be the result of encoding reason.
2. ~IF［ %事由~byte列を成す~byte数 ~GT 123 ］ ⇒ ~THROW `SyntaxError$E ◎ If reasonBytes is longer than 123 bytes, then throw a "SyntaxError" DOMException.
~IF［コレの`準備y状態$wS ~IN { `CLOSING$m, `CLOSED$m } ］ ⇒ ~RET ◎ 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$et ~eventが発火されることになる。 ◎ The connection is already closing or is already closed. If it has not already, a close event will eventually fire as described below.
~ELIF［ `~WebSocket接続は確立-済み$wsでない `WSP$r ］ ⇒＃ `~WebSocket接続を失敗させる$ws；コレの`準備y状態$wS ~SET `CLOSING$m ◎ If the WebSocket connection is not yet established [WSP] • Fail the WebSocket connection and set this's ready state to CLOSING (2). [WSP]

注記： `~WebSocket接続を失敗させる$ws~algoは ⇒ `~WebSocket接続を~closeする$ws~algoを呼出す ⇒ それにより，`~WebSocket接続は~close済み$wsになる ⇒ それに伴い，`後述のように$ `close$et ~eventが発火されることになる。 ◎ 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.
~ELIF［ `~WebSocket~closing~handshakeは開始-済み$wsでない］： ◎ If the WebSocket closing handshake has not yet been started [WSP]
1. `~WebSocket~closing~handshakeを開始する$ws： ◎ Start the WebSocket closing handshake＼ ↓and set this's ready state to CLOSING (2). [WSP]
  - ［ %code ~EQ ε ］~AND［ %reason ~EQ ε ］ならば ⇒ `Close ~message$wsは，~bodyを持たないモノトスル。 ◎ If neither code nor reason is present, the WebSocket Close message must not have a body.
    
    注記： `WSP$r は、［ `~WebSocket~closing~handshakeを開始する$ws~algoに状態s~codeが要求される］ものと，誤って言明している。 ◎ The WebSocket Protocol erroneously states that the status code is required for the start the WebSocket closing handshake algorithm.
  - ［ %code ~NEQ ε ］ならば ⇒ `Close ~message$wsに利用する`状態s~code$wsは、 %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 ~NEQ ε ］~AND［ %reason ~NEQ ε ］ならば ⇒ `Close ~message$wsには，`状態s~code$wsに加えて %reason も供するモノトスル。 ◎ If reason is also present, then reasonBytes must be provided in the Close message after the status code. [WSP]
2. コレの`準備y状態$wS ~SET `CLOSING$m ◎ ↑
注記： `~WebSocket~closing~handshakeを開始する$ws~algoは ⇒ 最終的には`~WebSocket接続を~closeする$ws~algoを呼出すことになる ⇒ それにより，`~WebSocket接続は~close済み$wsになる ⇒ それに伴い，`後述のように$ `close$et ~eventが発火されることになる。 ◎ 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.
~ELSE ⇒ コレの`準備y状態$wS ~SET `CLOSING$m ◎ Otherwise • Set this's ready state to CLOSING (2).

注記： `~WebSocket~closing~handshakeは開始-済み$wsであり ⇒ 最終的には`~WebSocket接続を~closeする$ws~algoを呼出すことになる ⇒ それにより，`~WebSocket接続は~close済み$wsになる ⇒ それに伴い，`後述のように$ `close$et ~eventが発火されることになる。 ◎ 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()$m ~methodは、［ `~WebSocket~closing~handshakeを開始する$ws以前に送信した~message ］を破棄するものではない — 仮に，~UAがそのような~messageをまだ送信-中であったとしても、 ~handshakeが開始されるのは，その~messageを送信した後に限られることになる。 ◎ 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@m 取得子~手続きは、 ~app~data（~UTF-8~text~data, または~binary~data） — `send()$m により~queueされたが、 `~event~loop$がその`最初の段$に最後に達した時点では，~networkにまだ伝送されていないそれ — の~byte数を返す。（したがって、これは，現在の~taskの実行-中に伝送された~textを含む — ~UAが［ ~script実行と`並列的$に，背後で~textを伝送できるかどうか］にかかわらず）。これには、［ ~protocolから課される~frame法の~overhead／ ~OSや~network~hardwareによる~buffering ］は含まれない。 ◎ 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.

次の単純な例では、 `bufferedAmount$m 属性を利用して，毎 50ms ごとに一回の頻度で（あるいは，速すぎて~networkが追いつかない場合は追いつける頻度で）更新を送信する。 ◎ In this simple example, the bufferedAmount attribute is used to ensure that updates are sent either at the rate of one update every 50ms, if the network can handle that rate, or at whatever rate the network can handle, if that is too fast.

var %socket = new WebSocket('ws://game.example.com:12010/updates');
%socket.onopen = function () {
  setInterval(function() {
    if (%socket.bufferedAmount == 0) {
      %socket.send(getUpdateData());
    }
  }, 50);
};

`bufferedAmount$m 属性を利用すれば、 ~networkが追いつかない頻度で~dataを送信しなくとも， ~networkを使い切れるようになる（その属性の値を時間~越しに監視することに，もっと気を付ける必要はあるが）。 ◎ The bufferedAmount attribute can also be used to saturate the network without sending the data at a higher rate than the network can handle, though this requires more careful monitoring of the value of the attribute over time.

`binaryType@m 取得子~手続きは ⇒ ~RET コレの`~binary種別$wS ◎ The binaryType getter steps are to return this's binary type.

`binaryType@m 設定子~手続きは ⇒ コレの`~binary種別$wS ~SET 所与の値 ◎ The binaryType setter steps are to set this's binary type to the given value.

注記： ~UAは、受信した~binary~dataを取扱う方法~用の~hintとして，`~binary種別$wSを利用できる：これが `blob$l にされている場合、 ~dataは~diskへ安全に~spoolするに適するものになる。 `arraybuffer$l にされている場合、より効率的に~memory内に保つに適するものになる。もちろん，~UAには、 ~~受信した~dataを~memory内に保つかどうか裁定するときに，より繊細な経験則を利用することが推奨される — 例：~data量や［直前における，~scriptによるこの属性に対する変更の頻度］を基準にするなど。この後者の側面は、特に重要になる — ~UAが［ ~dataを受信した後, かつそれ用の~eventを発火する前］に，この属性が変更される可能性も少なからずあるので。 ◎ User agents can use the binary type as a hint for how to handle incoming binary data: if it is "blob", it is safe to spool it to disk, and if it is "arraybuffer", it is likely more efficient to keep the data in memory. Naturally, user agents are encouraged to use more subtle heuristics to decide whether to keep incoming data in memory or not, e.g. based on how big the data is or how common it is for a script to change the attribute at the last minute. This latter aspect is important in particular because it is quite possible for the attribute to be changed after the user agent has received the data but before the user agent has fired the event for it.

`send(data)@m その~method手続きは： ◎ The send(data) method steps are:

~IF［コレの`準備y状態$wS ~EQ `CONNECTING$m ］ ⇒ ~THROW `InvalidStateError^E ◎ If this's ready state is CONNECTING, then throw an "InvalidStateError" DOMException.

~IF［ `~WebSocket接続は確立-済み$wsである］~AND［ `~WebSocket~closing~handshakeは開始-済み$wsでない【すなわち，`準備y状態$wS ~EQ `OPEN$m 】］ ⇒ %data 引数の型に応じて，下の表tに与えられる［ `~opcode$ws, および`~payload~data$ws ］から構成される`~WebSocket~messageを送信する$ws ⇒ ~bufferを要する所で~bufferが満杯になっているなどの~~理由で，~dataを送信できない場合 ⇒ この接続の`満杯か$を ~T にした上で，`~WebSocket接続を~closeする$ws

引数の型	`~opcode$ws	`~payload~data$ws
`DOMString`	~text~frame（数値 1 ）	`~UTF-8符号化する$( %data ) の結果。 `UNICODE$r `ENCODING$r
`Blob$I	~binary~frame（数値 2 ）	%data が表現する生~data。 `FILEAPI$r
`ArrayBuffer$I		%data が表現する~bufferに格納されている~data。
`ArrayBufferView$I		%data が参照している，下層の `ArrayBuffer$I ~objが格納する~bufferの中の一区分。

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

◎ 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]

【！この~methodの被呼出時に，例外を投出しない場合は、】 `bufferedAmount$m 属性の値 ~INCBY 前~段による`~payload~data$wsに要する~byte数 ◎ ↑

`WebSocket$I ~interfaceを実装する~objは、次の表tに挙げる［ `~event~handler$, それに対応する `~event~handler~event型$ ］を`~event~handler~IDL属性$として~supportするモノトスル： ◎ The following are the event handlers (and their corresponding event handler event types) that must be supported, as event handler IDL attributes, by all objects implementing the WebSocket interface:

`~event~handler$	`~event~handler~event型$
`onopen@m	`open$et
`onmessage@m	`message$et
`onerror@m	`error$et
`onclose@m	`close$et

4. ~protocolからの~feedback

~UAは、 ~WebSocket接続を`確立-$wsしたときは，次の手続きを走らす`~taskを~queueする$モノトスル： ◎ When the WebSocket connection is established, the user agent must queue a task to run these steps:

%O ~LET 当の `WebSocket$I ~obj ◎ ↓
%O の`準備y状態$wS ~SET `OPEN$m ◎ Change the ready state to OPEN (1).
~IF［ `利用-中にある拡張$ws ~NEQ ~NULL 値］ ⇒ %O の `extensions$m 属性~値 ~SET `利用-中にある拡張$ws ◎ Change the extensions attribute’s value to the extensions in use, if it is not the null value. [WSP]
~IF［ `利用-中にある下位protocol$ws ~NEQ ~NULL 値］ ⇒ %O の `protocol$m 属性~値 ~SET その値 `WSP$r ◎ Change the protocol attribute’s value to the subprotocol in use, if it is not the null value. [WSP]
`~eventを発火する$( %O, `open@et ) ◎ Fire an event named open at the WebSocket object.

注記：上の~algoは、 ~taskとして`~queueされ$るので，［ `確立-$wsされる~WebSocket接続, `open$et ~event用に~event~listenerを設定しておく~script ］との間で競争が生じることはない。【すなわち、 `new WebSocket()$m を呼出した後に同期的に登録された~event~listenerが，~serverからの初期~messageを受け取り損ねることはない。】 ◎ Since the algorithm above is queued as a task, there is no race condition between the WebSocket connection being established and the script setting up an event listener for the open event.

~UAは， `~WebSocket~messageを受信した$wsときは、所与の ( %種別, %~data ) に対し，次の手続きを走らす`~taskを~queueする$モノトスル： ◎ When a WebSocket message has been received with type type and data data, the user agent must queue a task to follow these steps: [WSP]

【 %~data は、当の~message内に受信した`~payload~data$wsを表す。 %種別 ~IN { `Text^i, `Binary^i } は、 ~messageの`~frame種別＠~RFC6455#section-5.6$から指示される %~data の種別を表す。】

%O ~LET 当の `WebSocket$I ~obj ◎ ↓
~IF［ %O の`準備y状態$wS ~NEQ `OPEN$m ］ ⇒ ~RET ◎ If ready state is not OPEN (1), then return.
%~event用の~data ~LET %種別に応じて ⇒＃ `Text^i ならば %~data を内容とする，新たな `DOMString^I ／ `Binary^i ならば %O の`~binary種別$wSに応じて：
- `blob@l ⇒ %O に`関連な~realm$内の新たな `Blob$I ~obj `FILEAPI$r — その`~byte列~data$として %~data を伴う
- `arraybuffer@l ⇒ %O に`関連な~realm$内の新たな `ArrayBuffer$I ~obj — その~buffer内容として %~data を伴う
◎ Let dataForEvent be determined by switching on type and binary type: ◎ type indicates that the data is Text • a new DOMString containing data ◎ type indicates that the data is Binary and binary type is "blob" • a new Blob object, created in the relevant Realm of the WebSocket object, that represents data as its raw data [FILEAPI] ◎ type indicates that the data is Binary and binary type is "arraybuffer" • a new ArrayBuffer object, created in the relevant Realm of the WebSocket object, whose contents are data
`~eventを発火する$( %O, `message@et, `MessageEvent$I ) — 次のように初期化して ⇒＃ `origin$m 属性 ~SET `生成元を直列化する$【！`~URLを直列化する$】( %O の`~URL$wSの`生成元$url ), `data$m 属性 ~SET %~event用の~data ◎ Fire an event named message at the WebSocket object, using MessageEvent, with the origin attribute initialized to the serialization of the WebSocket object’s url's origin, and the data attribute initialized to dataForEvent.

注記： ~UAには、［上で~queueした`~task$ %~task を効率的に遂行できるかどうか］を［ %~task を走らす前に検査しておく］ことが推奨される — 効率的に遂行できないときは、 ~bufferを準備する間は，他の`~task~queue$から`~task$を選取る等。例えば，［ ~dataの到着-時には、 `~binary種別$wSは `blob$l にされていて， ~UAはすべての~dataを~diskへ~spool済みであった］が［当の~message用に %~task を走らす直前に， ~scriptが`~binary種別$wSを `arraybuffer$l に切替えた］場合、 ~UAは — `ArrayBuffer$I ~objを作成している間に~main~threadが停滞しないよう — %~task を走らす前に~dataを~RAMに戻したいと求めるであろう。 ◎ User agents are encouraged to check if they can perform the above steps efficiently before they run the task, picking tasks from other task queues while they prepare the buffers if not. For example, if the binary type is "blob" when the data arrived, and the user agent spooled all the data to disk, but just before running the above task for this particular message the script switched binary type to "arraybuffer", the user agent would want to page the data back to RAM before running this task so as to avoid stalling the main thread while it created the ArrayBuffer object.

~text~frameの場合に `message$et ~event用に~handlerを定義する例： ◎ Here is an example of how to define a handler for the message event in the case of text frames:

%mysocket.onmessage = function (%event) {
  if (%event.data == 'on') {
    turnLampOn();
  } else if (%event.data == 'off') {
    turnLampOff();
  }
};

ここでの~protocolは、［ ~serverが "on" または "off" ~messageを送信するだけの，単純なもの］とする。 ◎ The protocol here is a trivial one, with the server just sending "on" or "off" messages.

~UAは、 `~WebSocket~closing~handshakeを開始した$wsときは，次を走らす`~taskを~queueする$モノトスル： ◎ When the WebSocket closing handshake is started, the user agent must＼

当の `WebSocket$I ~objの`準備y状態$wS ~SET `CLOSING$m ◎ queue a task to change the ready state to CLOSING (2).＼

（ `close()$m ~methodが~callされていた場合、 `準備y状態$wSは，この~taskを走らす時点で，すでに `CLOSING$m に設定されていることになる。） ◎ (If the close() method was called, the ready state will already be set to CLOSING (2) when this task runs.) [WSP]

~UAは、 ~WebSocket接続が`~closeされ$wsたときは（`~cleanに~closeされた$ws場合も含む），次の手続きを走らす`~taskを~queueする$モノトスル： ◎ When the WebSocket connection is closed, possibly cleanly, the user agent must queue a task to run the following substeps:

%O ~LET 当の `WebSocket$I ~obj ◎ ↓
%O の`準備y状態$wS ~SET `CLOSED$m ◎ Change the ready state to CLOSED (3).
~IF［ ~UAは`~WebSocket接続を失敗させる$ws必要がある］~OR［ ~WebSocket接続はその `満杯か@ （初期~時は ~F ）が ~T にされた上で`~closeされ$wsた］ ⇒ `~eventを発火する$( %O, `error@et ) ◎ If the user agent was required to fail the WebSocket connection, or if the WebSocket connection was closed after being flagged as full, fire an event named error at the WebSocket object. [WSP]
`~eventを発火する$( %O, `close@et, `CloseEvent$I ) — 次のように初期化して ⇒＃ `wasClean$m 属性 ~SET ~IS［接続は`~cleanに~closeされた$ws ］, `code$m 属性 ~SET `~WebSocket接続~close~code$ws, `reason$m 属性 ~SET `~BOMはそのままに~UTF-8復号する$( `~WebSocket接続~close事由$ws ) ◎ Fire an event named close at the WebSocket object, using CloseEvent, with the wasClean attribute initialized to true if the connection closed cleanly and false otherwise, the code attribute initialized to the WebSocket connection close code, and the reason attribute initialized to the result of applying UTF-8 decode without BOM to the WebSocket connection close reason. [WSP]

警告： ~UAは、次に挙げる状況を判別し得るような失敗~情報は，~scriptに伝達しないモノトスル： ◎ User agents must not convey any failure information to scripts in a way that would allow a script to distinguish the following situations:

~serverの~host名を解決できなかった。 ◎ A server whose host name could not be resolved.
~serverへ~packetを成功裡に~routeできなかった。 ◎ A server to which packets could not successfully be routed.
指定された~portへの接続を~serverが拒否した。 ◎ A server that refused the connection on the specified port.
~serverとの TLS ~handshakeを正しく遂行できなかった（例：~serverの証明書を検証yできなかった）。 ◎ A server that failed to correctly perform a TLS handshake (e.g., the server certificate can’t be verified).
~serverが~opening~handshakeを完了しなかった（例：~serverが~WebSocket~serverではなかった）。 ◎ A server that did not complete the opening handshake (e.g. because it was not a WebSocket server).
~WebSocket~serverは正しい~opening~handshakeを送信したが、それが指定する~optionにより，~clientは接続を落とした（例：~serverは~clientが提供しなかった`下位protocol$wsを指定してきた）。 ◎ A WebSocket server that sent a correct opening handshake, but that specified options that caused the client to drop the connection (e.g. the server specified a subprotocol that the client did not offer).
~WebSocket~serverは~opening~handshakeを成功裡に完了した後に突如，接続を~closeした。 ◎ A WebSocket server that abruptly closed the connection after successfully completing the opening handshake.

これらのどの事例でも、 `~WebSocket接続~close~code$wsは 1006 になる — `WSP$r により要求されるとおり。 ◎ In all of these cases, the WebSocket connection close code would be 1006, as required by WebSocket Protocol. [WSP]

~scriptがこれら各~事例を判別できるようになると、［攻撃の準備として，利用者の~local~networkを探査する］ことを~scriptに許容することになる。 ◎ Allowing a script to distinguish these cases would allow a script to probe the user’s local network in preparation for an attack.

注記：特に，このことは、 ~code 1015 は，~UAからは利用されないことを意味する（もちろん、 ~serverが `Close ~frame$wsに誤って利用した場合は除く）。 ◎ In particular, this means the code 1015 is not used by the user agent (unless the server erroneously uses it in its close frame, of course).

この節にて`~queueされ$るどの`~task$も，その`~task~source$は `~WebSocket~task~source@ とする。 ◎ The task source for all tasks queued in this section is the WebSocket task source.

5. Ping ~frameと Pong ~frame

`WSP$r は、［接続維持, 鼓動, ~network状態探針, 待時間の計測, 等々］に利用できる［ `Ping ~frame$ws, `Pong ~frame$ws ］を定義する。これらは、現時点では~APIに公開されていない。 ◎ The WebSocket protocol defines Ping and Pong frames that can be used for keep-alive, heart-beats, network status probing, latency instrumentation, and so forth. These are not currently exposed in the API.

~UAは、欲されるなら［ `Ping ~frame$ws ／請求されていない `Pong ~frame$ws ］を送信してもヨイ — 例えば［ ~local~network~NATmappingを保守する／接続を検出する／利用者に待時間を表示する］などの試みの一環として。 ~UAは、これらの~frameを~serverの援助-用として利用しないモノトスル — ~serverは、必要に応じて適切な時機に~pongを請求するものと見做されているので。 ◎ User agents may send ping and unsolicited pong frames as desired, for example in an attempt to maintain local network NAT mappings, to detect failed connections, or to display latency metrics to the user. User agents must not use pings or unsolicited pongs to aid the server; it is assumed that servers will solicit pongs whenever appropriate for the server’s needs.

6. `CloseEvent^I ~interface

`WebSocket$I ~objは、その `close$et ~event用に `CloseEvent$I ~interfaceを利用する： ◎ WebSocket objects use the CloseEvent interface for their close events:

[`Exposed$=(Window,Worker)]
interface `CloseEvent@I : `Event$I {
  `constructor＠~DOM4#concept-event-constructor$(`DOMString$ %type, optional `CloseEventInit$I %eventInitDict = {});

  readonly attribute `boolean$ `wasClean$m;
  readonly attribute `unsigned short$ `code$m;
  readonly attribute `USVString$ `reason$m;
};

dictionary `CloseEventInit@I : `EventInit$I {
  `boolean$ `wasClean@mb = false;
  `unsigned short$ `code@mb = 0;
  `USVString$ `reason@mb = "";
};

%event.`wasClean$m: ［接続は`~cleanに~closeされた$wsならば ~T ／ ~ELSE_ ~F ］を返す。 ◎ Returns true if the connection closed cleanly; false otherwise.
%event.`code$m: ~serverから供された`~WebSocket接続~close~code$wsを返す。 ◎ Returns the WebSocket connection close code provided by the server.
%event.`reason$m: ~serverから供された`~WebSocket接続~close事由$wsを返す。 ◎ Returns the WebSocket connection close reason provided by the server.

`wasClean@m 取得子~手続きは、初期化-時の値を返す。それは、［接続が`~cleanに~closeされた$wsかどうか］を表現する。 ◎ The wasClean attribute must return the value it was initialized to.＼ It represents whether the connection closed cleanly or not.

`code@m 取得子~手続きは、初期化-時の値を返す。それは、［ ~serverから供された`~WebSocket接続~close~code$ws ］を表現する。 ◎ The code attribute must return the value it was initialized to.＼ It represents the WebSocket connection close code provided by the server.

`reason@m 取得子~手続きは、初期化-時の値を返す。それは、［ ~serverから供された`~WebSocket接続~close事由$ws ］を表現する。 ◎ The reason attribute must return the value it was initialized to.＼ It represents the WebSocket connection close reason provided by the server.

7. ~garbage収集

次のいずれかに該当する `WebSocket$I ~objは、 ~garbage収集しないモノトスル： ◎ ↓

`~event~loop$がその`最初の段$に最後に達した時点で、 `準備y状態$wSが［次の表tの 1 列目に挙げる値］にされていて，［同じ行の 2 列目に示される~event型に対し登録されている~event~listenerが在る］もの。

`準備y状態$wS `~event~handler~event型$
`CONNECTING$m (0) `open$et, `message$et, `error$et, `close$et
`OPEN$m (1) `message$et, `error$et, `close$et
`CLOSING$m (2) `error$et, `close$et
◎ A WebSocket object whose ready state was set to CONNECTING (0) as of the last time the event loop reached step 1 must not be garbage collected if there are any event listeners registered for open events, message events, error events, or close events. ◎ A WebSocket object whose ready state was set to OPEN (1) as of the last time the event loop reached step 1 must not be garbage collected if there are any event listeners registered for message events, error, or close events. ◎ A WebSocket object whose ready state was set to CLOSING (2) as of the last time the event loop reached step 1 must not be garbage collected if there are any event listeners registered for error or close events.
`~WebSocket接続は確立-済み$wsであり，~network伝送-用に~dataが~queueされているもの。 ◎ A WebSocket object with an established connection that has data queued to be transmitted to the network must not be garbage collected. [WSP]

`準備y状態$wS	`~event~handler~event型$
`CONNECTING$m (0)	`open$et, `message$et, `error$et, `close$et
`OPEN$m (1)	`message$et, `error$et, `close$et
`CLOSING$m (2)	`error$et, `close$et

接続が~openしているにもかかわらず， `WebSocket$I ~objが~garbage収集された場合、 ~UAは，`~WebSocket~closing~handshakeを開始する$wsモノトスル。このときの `Close ~message$wsは、 `状態s~code$wsを伴わないものとする。 ◎ If a WebSocket object is garbage collected while its connection is still open, the user agent must start the WebSocket closing handshake, with no status code for the Close message. [WSP]

~UAは， `WebSocket$I ~objを `消滅させる@ 必要が生じたときは（これは、 `Document$I ~objが消え去るとき起こる）、次を走らすモノトスル： ◎ If a user agent is to make disappear a WebSocket object (this happens when a Document object goes away), the user agent must follow the first appropriate set of steps from the following list:

~IF［ `~WebSocket接続は確立-済み$wsでない］ ⇒ `~WebSocket接続を失敗させる$ws ◎ If the WebSocket connection is not yet established [WSP] • Fail the WebSocket connection. [WSP]
~ELIF［ `~WebSocket~closing~handshakeは開始-済み$wsでない］ ⇒ `~WebSocket~closing~handshakeを開始する$ws — `Close ~message$wsに利用する`状態s~code$wsは 1001 とする ◎ If the WebSocket closing handshake has not yet been started [WSP] • Start the WebSocket closing handshake, with the status code to use in the WebSocket Close message being 1001. [WSP] ◎ Otherwise • Do nothing.

謝辞

2021年におけるこの標準の作成まで、ここにある~textは， `HTML^cite と `Fetch^cite にて保守されていた。これら各~仕様の~repositoryに貢献してこの仕様の開発に助力された，すべての方々に — とりわけ、これら各~仕様の元の作者である `Ian Hickson^en, `Anne van Kesteren^en 各氏（同順）に。 ◎ Until the creation of this standard in 2021, the text here was maintained in the HTML Standard and Fetch Standard. Thanks to all of the contributors to those repositories who helped develop the specification, especially Ian Hickson and Anne van Kesteren as the respective original authors.

この標準が作成された後における，次に挙げる各氏による貢献に ⇒＃ `devsnek^, 平野裕（ `Yutaka Hirano^en ） ◎ Thanks to devsnek and 平野裕 (Yutaka Hirano) for their contributions after the creation of the WebSockets Standard.

この標準は、 `Adam Rice^en （ Google, ricea@chromium.org ）により書かれた。 ◎ This standard is written by Adam Rice (Google, ricea@chromium.org).

`_acks1@

知的財産権

`_ipr1@