[25] ws: は WebSocket over TCP、 wss: は WebSocket over TLS over TCP によってアクセスできる WebSocket 資源を表す URL scheme です。

仕様書

構文

[3] URL scheme、://、 authority、path、 省略可能な query で構成されます。 query がある場合は、 直前に ? が必要です。 >>2

  1. URL scheme
  2. ://
  3. authority
  4. path
  5. ?
    1. ?
    2. query

[12] 素片識別子を使ってはなりません >>2。

URL scheme

[4] URL scheme は、 ws または wss です >>2。

[10] wss であれば、当該 URL は「保安」"secure"であり、 the secure flag is set といいます >>2。

authority

[5] authority は、ホストと、省略可能な port です。 port がある場合は直前に : が必要です。 >>2

  1. ホスト
  2. ?
    1. :
    2. port

[6] ホストと port は、 RFC 3986 の定義が参照されています >>2。 現実には URL Standard に従い解釈されるものと思われます。

[9] ws: の既定のポートは 80、 wss: の既定のポートは 443 です >>2。

資源名

[7] path は、 RFC 3986 path-abempty です >>2。

[8] query は、 RFC 3986 query が参照されています >>2。

[11] 資源名resource nameは、

  1. path が空なら、 /
  2. path
  3. query が非空なら、 ?
  4. query

... を連結したものです >>2。

[21] 資源名の解釈は、 HTTP の場合と同じく、サーバーに委ねられています。 クライアントはその意味を一般的に解釈することはできません。

[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。

  1. 入力が絶対URLでなければ、失敗を返し、停止します。
  2. 入力についてURLの解決を行います。URL文字符号化は、 UTF-8 とします。 基底URLは何でも構いません。
  3. 解決結果の URL scheme が ws か wss でなければ、失敗を返し、停止します。
  4. 解決結果に素片識別子があれば、失敗を返し、停止します。
  5. secure を、URL scheme が wss なら真、ws なら偽に設定します。
  6. ホストを、解決結果のホストに設定します。
  7. 解決結果に空文字列以外のポートがあれば、
    1. ポートを、指定されたポートに設定します。
  8. それ以外なら、
    1. ポートを、secure が真なら 443、そうでないなら 80 に設定します。
  9. 資源名に、解決結果のパスを設定します。ただし空文字列なら、 / に設定します。
  10. 解決結果に URL query があるなら、資源名の末尾に ? と query を追加します。
  11. ホスト、ポート、資源名、secure を返します。

比較

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

HTTP URL への変換

[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 に適用されるのかどうかも曖昧でした。

歴史

[26] Fix #244: improve HSTS language · whatwg/fetch@6568ab8 ( 版) https://github.com/whatwg/fetch/commit/6568ab88c1fbfb581f63f8e5f020c367ef38e78d

[27] Update WebSocket to use Fetch's WebSocket alterations · whatwg/html@3dadbca ( 版) https://github.com/whatwg/html/commit/3dadbcad063a10b586ef52dd4b427aa339048ee7