代替サービス広告

[19] 起源サーバーは、 プロトコルの識別子を代替サービスとして広告します。 ここで、プロトコルは、 TLS を使うもの (例えば h2) とします。 プロトコルは、資源の scheme を明示的に示すものでなければなりません。 >>12

[21] クライアントは、そのような代替サービスの広告を受信したら、 以後その起源への要求を指定された代替サービス経由で送信して構いません。 >>12

[23] クライアントは、代替サービスの接続の準備が完了するまで、 要求の送信を遅延させることができます。その場合、接続に失敗したら、 通常の平文の接続で送信することになります。 >>12

[22] クライアントは、まず OPTIONS 要求のような繊細な情報が少ない要求を送信して、 代替サービスが無いか確認することもできます。 >>12

[24] クライアントは、既知の代替サービスの満期が近い時、 OPTIONS 要求のようなものを予め送信しておき、 代替サービス情報を更新することもできます。 >>12

[51] 代替サービスの広告は素のHTTPで送受信されますから、改竄の可能性があります。 例えば Alt-Svc: ヘッダーを削除することで、 downgrade attack が可能です >>12。

TLS ハンドシェイク

[25] クライアント証明書は、意味を持ちません。 クライアントは、 クライアント証明書を指定してはなりません。 >>12

[26] サーバーは、同じポートで https: も提供する場合に、 証明書要求することができます。 しかし、クライアントが証明書を提供しない場合にも、 ハンドシェイクを中断 (abort) してはなりません。 >>12

[30] 代替サービスにおける「十分な保証」は、HTTPSサーバー認証を使うことによります。 クライアントは、 HTTPSサーバー認証によりサーバー証明書が要求の起源について妥当である場合を除き、 当該接続で要求を送信してはなりません。 >>12

最初の要求

[31] クライアントは、 まず要求の起源に関して妥当な「http-opportunistic」応答を得なければなりません。 >>12

[35] 起源について妥当な「http-opportunistic」応答を持つ (have a valid "http-opportunistic" response) とは、 次の条件を満たすことをいいます。 >>12

[44] (配列に?) 含まれる値が文字列でない時、非妥当として構いません。 >>12

[46] 新鮮であるとの条件が暗示する通り、HTTPキャッシュの利用が認められています。 したがって、すべての代替サービスが http://.../.well-known/http-opportunistic に応答できる必要があります >>12。 クライアントは、当該代替サービスから http://.../.well-known/http-opportunistic を取得せずとも (キャッシュを使って) すぐに利用できます >>12。

[47] クライアントは、認証されていない接続を使って得た http://.../.well-known/http-opportunistic のキャッシュを使ってはなりません >>12。

[49] クライアントは、認証されていない接続を使って得た http://.../.well-known/http-opportunistic がキャッシュにあっても、消去しなければなりません。 認証されていない接続の応答を認証された接続で再検証したところで、 応答の一貫性は保てません。 >>12

[53] http://.../.well-known/http-opportunistic の検査が必要なのは、 従来 HTTPS でアクセスされた時 https: のアクセスとみなして応答を返す運用がなされてきたため、 真に Opportunistic HTTP/2 Security を意図したサーバーかどうかを確認するためです >>12。

接続の利用

[32] クライアントは、 同じ接続に異なる起源の要求を送信してはなりません。 >>12