メインコンテンツまでスキップ

2. ORIGIN HTTP/2 フレーム (The ORIGIN HTTP/2 Frame)

このドキュメントでは、ORIGIN と呼ばれる新しい HTTP/2 フレームタイプ ([RFC7540]、セクション 4) を定義し、サーバーが、ORIGIN フレームが発生する接続のオリジンセット (セクション 2.3) のメンバーとしてクライアントに考慮してもらいたいオリジン [RFC6454] を示すことができるようにします。

2.1. 構文​

ORIGIN フレームタイプは 0xc (10 進数で 12) であり、Origin-Entry フィールドの 0 個以上のインスタンスを含みます。

+-------------------------------+-------------------------------+
|         Origin-Entry (*)                                    ...
+-------------------------------+-------------------------------+

Origin-Entry は、長さで区切られた文字列です。

+-------------------------------+-------------------------------+
|         Origin-Len (16)       | ASCII-Origin?               ...
+-------------------------------+-------------------------------+

具体的には：

Origin-Len: ASCII-Origin フィールドの長さをオクテット単位で示す符号なし 16 ビット整数。

Origin: 送信者がこの接続が権限を持つ、または持つ可能性があると主張するオリジン ([RFC6454]、セクション 6.2) の ASCII シリアル化を含むオプションの文字シーケンス。

ORIGIN フレームはフラグを定義しません。ただし、この仕様の将来の更新でフラグが定義される可能性があります (MAY)。セクション 2.2 を参照してください。

2.2. ORIGIN フレームの処理​

ORIGIN フレームは、HTTP/2 への重要ではない拡張です。このフレームをサポートしていないエンドポイントは、受信時に安全に無視できます。

実装しているクライアントが受信すると、オリジンセット (セクション 2.3 を参照) を初期化および操作するために使用され、それによってクライアントがオリジンサーバーの権限を確立する方法が変更されます (セクション 2.4 を参照)。

ORIGIN フレームはストリーム 0 で送信しなければなりません (MUST)。他のストリーム上の ORIGIN フレームは無効であり、無視しなければなりません (MUST)。

同様に、ORIGIN フレームは、「h2」プロトコル識別子を持つ接続、またはプロトコルの定義によって具体的に指名された場合にのみ有効です。「h2c」プロトコル識別子を持つ接続で受信した場合は無視しなければなりません (MUST)。

この仕様では ORIGIN フレームのフラグは定義されていませんが、この仕様の将来の更新 (IETF の合意による) では、セマンティクスを変更するためにフラグが使用される可能性があります。最初の 4 つのフラグ (0x1、0x2、0x4、および 0x8) は、下位互換性のない変更のために予約されています。したがって、それらのいずれかが設定されている場合、それらを含む ORIGIN フレームは、フラグのセマンティクスが理解されない限り、この仕様に準拠するクライアントによって無視されなければなりません (MUST)。残りのフラグは、下位互換性のある変更のために予約されており、この仕様に準拠するクライアントによる処理には影響しません。

ORIGIN フレームは接続のプロパティを記述するため、ホップバイホップで処理されます。仲介者は ORIGIN フレームを転送してはなりません (MUST NOT)。プロキシを使用するように構成されたクライアントは、プロキシから受信した ORIGIN フレームを無視しなければなりません (MUST)。

フレームのペイロード内の各 ASCII-Origin フィールドは、オリジンの ASCII シリアル化として解析されなければなりません (MUST) ([RFC6454]、セクション 6.2)。解析が失敗した場合、フィールドは無視されなければなりません (MUST)。

ORIGIN フレームは、Origin-Entry でワイルドカード名 (例: "*.example.com") をサポートしていないことに注意してください。その結果、ワイルドカード証明書が使用されているときに ORIGIN を送信すると、ORIGIN フレームに明示的にリストされていないオリジンは事実上無効になります (クライアントが ORIGIN を理解している場合)。

ORIGIN フレームを処理するための例示的なアルゴリズムについては、付録 A を参照してください。

2.3. オリジンセット​

特定の接続が使用される可能性のあるオリジンのセット ([RFC6454] に従う) は、この仕様ではオリジンセットとして知られています。

デフォルトでは、接続のオリジンセットは初期化されていません。初期化されていないオリジンセットは、クライアントが [RFC7540] のセクション 9.1.1 の結合ルールを適用することを意味します。

ORIGIN フレームが最初に受信され、クライアントによって正常に処理されると、接続のオリジンセットは初期オリジンを含むように定義されます。初期オリジンは以下から構成されます。

  • スキーム: "https"
  • ホスト: Server Name Indication (SNI) ([RFC6066]、セクション 3) で送信された値を小文字に変換したもの。SNI が存在しない場合は、接続のリモートアドレス (つまり、サーバーの IP アドレス)
  • ポート: 接続のリモートポート (つまり、サーバーのポート)

その ORIGIN フレーム (および後続のフレーム) の内容により、サーバーはセクション 2.2 で説明されているように、新しいオリジンをオリジンセットに段階的に追加できます。

オリジンセットは、[RFC7540] のセクション 9.1.2 で定義されている 421 (Misdirected Request) レスポンスステータスコードの影響も受けます。このステータスコードを含むレスポンスを受信すると、実装しているクライアントは、対応するリクエストのオリジンの ASCII シリアル化を作成し ([RFC6454]、セクション 6.2 に従う)、存在する場合は接続のオリジンセットから削除しなければなりません (MUST)。

注: 代替サービス [RFC7838] として初期化された接続に ORIGIN フレームを送信する場合、初期オリジンセット (セクション 2.3) には適切なスキームとホスト名を持つオリジンが含まれます (RFC 7838 ではオリジンのホスト名を SNI で送信することが指定されているため)。ただし、初期オリジンセットは実際に使用されているポートを使用して計算されるため、ポートが意図したオリジンのポートとは異なる可能性があります (代替サービスの場合は異なる可能性があります)。この場合、意図したオリジンを ORIGIN フレームで明示的に送信する必要があります。

たとえば、"https://example.com" へのリクエストを行うクライアントは、("h2", "x.example.net", "8443") の代替サービスに誘導されます。この代替サービスが ORIGIN フレームを送信する場合、初期オリジンは "https://example.com:8443" になります。クライアントは、そのオリジンが ORIGIN フレームに明示的に含まれていない限り、代替サービスを使用して "https://example.com" へのリクエストを行うことはできません。

2.4. 権限、プッシュ、および ORIGIN による結合​

[RFC7540] のセクション 10.1 では、HTTP/1.1 が [RFC7230] で行うのと同様に、DNS と提示された Transport Layer Security (TLS) 証明書の両方を使用して、接続が権限を持つオリジンサーバーを確立します。

さらに、[RFC7540] のセクション 9.1.1 では、権限がある場合、接続を複数のオリジンサーバーに使用することを明示的に許可しています。これは、リクエストへの直接レスポンスとサーバープッシュ ([RFC7540]、セクション 8.2.2 を参照) の両方について、どのレスポンスが正当と見なされるかに影響します。間接的には、クライアントは通常、問題のオリジンに対して権限があると信じる接続でのみリクエストを送信するため、接続で送信されるリクエストにも影響します。

接続に対してオリジンセットが初期化されると、この仕様を実装するクライアントは、それを使用して接続が何に対して権限を持つかを判断するのに役立てます。具体的には、そのようなクライアントは、オリジンセットに存在しないオリジンに対して接続が権限を持つと見なしてはならず (MUST NOT)、新しい接続を開く運用上の理由がない限り、接続が権限を持つオリジンセット内のオリジンへのすべてのリクエストにその接続を使用すべきです (SHOULD)。

接続が特定のオリジンに対して権限を持つと見なされるには、サーバーが適切なチェックに合格する証明書を使用して認証する必要があることに注意してください。詳細については、[RFC7540] のセクション 9.1.1 を参照してください。これには、ホストが証明書の "subjectAltName" フィールドの "dNSName" 値と一致することを確認することが含まれます ([RFC2818] で定義されたルールを使用。[RFC5280] のセクション 4.2.1.6 も参照)。

さらに、クライアントは、オリジンセット内のオリジンへの新しいリクエストに対して接続の権限を確立するために DNS を参照することを避けてもよい (MAY)。ただし、そうするクライアントは、セクション 4 で説明されているように、新たなリスクに直面します。

ORIGIN は接続が使用されるオリジンのセットを時間の経過とともに変更できるため、クライアントがいつでもオリジンへの実行可能な接続を複数持っている可能性があります。これが発生した場合、クライアントは、オリジンセットが別の接続のオリジンセットの適切なサブセットである接続で新しいリクエストを発行すべきではなく (SHOULD NOT)、未処理のリクエストがすべて満たされたら閉じるべきです (SHOULD)。

オリジンセットは、サーバーによって行われた代替サービス [RFC7838] の広告の影響を受けません。代替サービスを宣伝しても、サーバーが権限を持っているかどうかには影響しません。

に最終更新