[22] 例えば query を application/x-www-form-urlencoded 形式にすることができますが、そう解釈して良いのはサーバーと、サーバーがそのように解釈していることを知っているスクリプトだけです。サーバーがどう解釈するか事前に知識を得ていないクライアントがそのように解釈してはいけません。

[23] WebSocketコンストラクターは UTF-8 としてURLの解決を行うと規定されています。つまりスクリプトが非ASCII文字を query に含めると、 UTF-8 としてパーセント符号化されてサーバーに送信されます。パス部分の非ASCII文字も、 UTF-8 としてパーセント符号化されます。ですから、WebSocketクライアントはパーセント符号化を UTF-8 として解釈することが好ましいと思われます。

[24] 元々パーセント符号化されているものは再変換されませんから、 UTF-8 以外の文字コードやバイナリーデータを含めることも理論上は可能です。しかし実用上は常に UTF-8 を使うとするべきでしょう。

妥当性

[29] RFC は WebSocket接続の確立で URL の妥当性を確認することを求めていましたが、その検査方法の詳細は不明でした。その曖昧な規定は Fetch Standard と HTML Standard の規定の厳密化により死文化しました。

[13] WebSocket接続の確立は、 ws:/wss: URL が妥当なものであるかどうか確認し、非妥当なら失敗します。

[14] どのような検査か完全に明記はされていませんが、素片識別子が含まれる場合や、ポートが数値でない文字列の場合、// が含まれない場合などが該当しそうです。

[15] WebSocket の RFC は RFC 3986 を参照しているので非ASCII文字は使えないことになりますが、実際には URL Standard に従い構文解析・正準化が行われた後の URL が使われますから、非ASCII文字は正準化の段階で ASCII文字に変換されています。

構文解析

[28] かつては独自の構文解析の手続きが HTML Standard で規定されていましたが、その後 URL Standard が整備されたことから、削除されました。 ws: や wss: の URL も通常の URLの構文解析が行われた後、 new WebSocket の処理で最低限の検査を行い、プロトコルで利用されることになります。

[19] WebSocket URLの部品の構文解析 (parse a WebSocket URL's components) は、次のようにしなければなりません >>20。

[18] ホストを Punycode により表現するのとパーセント符号化により表現するのは等価です >>17。

[32] fetch は、 WebSocket の処理の場合、 URL scheme を WebSocket のものから HTTP のものに書き換えます。各種仕様の URL に基づく操作は書き換え後の状態で適用されます。

[33] 従って HSTS、Mixed Content、Upgrade-Insecure-Requests などは、 HTTP のみならず WebSocket にも同様の形で適用されます。

[30] RFC 時代は、 HTTP URL と WebSocket URL の関係性が曖昧でした。

[16] WebSocket接続の確立は、相当する http:/https: URL を使うことがあります。これは ws:/wss: にそれぞれ相当するものと思われますが、明記はされていません。

[31] HSTS が WebSocket に適用されるのかどうかも曖昧でした。