ブラウザーの要件

WebTransport は、ブラウザーとサーバーが HTTP/3 の上で双方向にデータをやり取りするための API です。 ブラウザーが WebTransport セッションを開くのは、信頼できる証明書を使った HTTP/3 の上だけです。 また、ブラウザーはどのページが要求したかをサーバーに伝えます。 wired が WebTransport を提供するのは HTTP/3（UDP の上で動くトランスポートプロトコル QUIC を土台にした HTTP）だけなので、ブラウザー、ネットワーク、証明書のすべてがそれを許す必要があります。

証明書

ブラウザーは、サーバーの証明書を次の 2 通りのどちらかで受け入れます。

• CA（認証局）が発行した証明書：通常の HTTPS サイトと同じく、サーバーの DNS 名に対して発行されたものです。 アプリが id.chain として渡すと、wired はその証明書チェーンを送ります。
• ピン留めした自己署名証明書：CA を介さず、サーバー自身の鍵で署名した証明書です。 ページは WebTransport オブジェクトを作るときに、証明書の SHA-256 ハッシュを serverCertificateHashes に渡します（これがピン留めです）。 W3C の WebTransport 仕様がこの方法で受け入れるのは、有効期間が 14 日以内で、鍵が ECDSA P-256（secp256r1）の証明書だけです。

wired が組み立てる自己署名証明書は、この 2 つの条件を満たします。 鍵は ECDSA P-256 で（id.cert_seed が署名用のスカラーです）、id.now_secs を設定すると、有効期間は now_secs から now_secs + 14 日までになります（src/crypto/pki/cert/p256cert/tbs.c の PC_VALIDITY_DAYS）。 ドメイン名ではなく IP アドレスを直接指定して接続するページでは、そのアドレスが証明書の SAN（Subject Alternative Name、証明書が有効な対象を列挙する欄）にも必要です（id.san_ipv4）。 ブラウザーが必要とするもの では、そうした証明書を組み立て、ページがピン留めするハッシュを表示します。

証明書が変わるとハッシュも変わります。 そのため、ページはハッシュを埋め込まずにサーバーから現在の値を取得し、サーバーは 14 日が過ぎる前に証明書を入れ替える必要があります。 証明書のホットリロード は、再起動せずに証明書を入れ替えます。

Origin ヘッダー

ブラウザーからの WebTransport リクエストには、必ずページの Origin（スキーム・ホスト・ポートの組で表した、ページの提供元）が付きます。 wired は、Origin ヘッダーがあるのに空のリクエストには 403 で答えます。 それ以外の Origin は、アプリが wt_origin_check を登録しない限りすべて受け入れます。 Origin ヘッダーの検査 では、1 つの Origin だけを許し、残りを拒否します。 インターネットから到達できるサーバーは、同じ検査をするべきです。 どのサイトのどのページも、そのサーバーへセッションを開こうと試みることができるからです。

ブラウザーとネットワークの対応

• ブラウザーが、HTTP/3 上の WebTransport API を実装している必要があります。 頼る前に、対象とするブラウザーの対応状況を確認してください。
• ネットワークが、サーバーのポートへの UDP を通す必要があります。 QUIC は UDP の上でしか動かず、wired には TCP へのフォールバックがないので、UDP を遮断するネットワークではセッションも開けません。
• ページ自体がセキュアコンテキスト（HTTPS で配信されるか、開発中の localhost）で動いている必要があります。 それ以外の平文 HTTP のページからは、WebTransport API を使えません。