附録 B. サーバーの運用上の考慮事項 (Operational Considerations for Servers)

ORIGIN フレームを使用すると、サーバーは特定の接続をどのオリジンに使用すべきかを示すことができます。このメカニズムを使用して宣伝されるオリジンのセットはサーバーの制御下にあります。サーバーはそれを使用する義務や、リクエストに応答できる可能性のあるすべてのオリジンを宣伝する義務はありません。

たとえば、空の ORIGIN フレームを送信することで、接続が SNI ベースのオリジンにのみ使用されることをクライアントに通知するために使用できます。または、ペイロードを含めることで、より多くのオリジンを示すことができます。

一般に、この情報は、新しい接続を開始する可能性のあるレスポンスの一部を送信する前に送信するのが最も便利です。たとえば、"Link" レスポンスヘッダーフィールド [RFC8288] や、レスポンス本文内のリンクなどです。

したがって、ORIGIN フレームは、接続上でできるだけ早く、理想的には HEADERS または PUSH_PROMISE フレームの前に送信されるべきです。

ただし、多数のオリジンを接続に関連付けることが望ましい場合、そのサイズのために、そうすることでエンドユーザーが認識する遅延が発生する可能性があります。その結果、最初に送信するオリジンの「コア」セットを選択し、後で（たとえば、接続がアイドル状態のときに）後続の ORIGIN フレームを使用して接続が使用されるオリジンのセットを拡張する必要がある場合があります。

とはいえ、送信者は単一の ORIGIN フレーム内にできるだけ多くのオリジンを含めることが推奨されます。クライアントはその場で接続を作成するかどうかを決定する必要があり、オリジンセットが多くのフレームに分割されている場合、その動作は最適ではない可能性があります。

送信者は、[RFC6454] のセクション 4、ステップ 5 に従って、ORIGIN ヘッダーの値はシリアル化の前に大文字と小文字を正規化する必要があることに注意してください。

最後に、代替サービス [RFC7838] をホストするサーバーは、ORIGIN を送信するときにオリジンを明示的に宣伝する必要があります。これは、オリジンセットのデフォルトの内容（セクション 2.3 に従う）には、以前に接続で使用されていたとしても、代替サービスのオリジンが含まれていないためです。