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

1. はじめに

HTTP は、コンテンツまたは表現のデータ整合性を保護する手段を定義していません。HTTP メッセージがエンドポイント間で転送される場合、TCP チェックサムや TLS レコード [TLS] などの下位層の機能またはプロパティは、ある程度の整合性保護を提供できます。ただし、トランスポート指向の整合性は、アプリケーション層に対して不透明であり、単一の接続の範囲のみをカバーするため、有用性は限定的です。HTTP メッセージは、多くの場合、別々の接続の連鎖上を移動します。接続間では、データ破損の可能性があります。HTTP 整合性メカニズムは、エンドポイント、または HTTP を使用するアプリケーションがデータ破損を検出し、それに対してどのように対処するかを選択する手段を提供できます。使用例の 1 つは、システム境界を越えた障害検出と診断を支援することです。

この文書では、HTTP の 2 つのダイジェスト整合性メカニズムを定義しています。1 つ目はコンテンツ整合性で、転送されたコンテンツ ([HTTP] のセクション 6.4) に作用します。2 つ目は表現データ整合性で、表現データ ([HTTP] のセクション 8.1) に作用します。これにより、複数のリクエストまたは接続を使用して取得された部分から再構築されたリソースの整合性を検証するなど、高度な使用例がサポートされます。

この文書は [RFC3230] を廃止するため、Digest および Want-Digest HTTP フィールドも廃止されます。セクション 1.3 を参照してください。

1.1. 文書構成​

この文書の構成は以下の通りです：

  • 新しいリクエストおよびレスポンスヘッダーとトレーラーフィールドの定義。

    • セクション 2 (Content-Digest)、
    • セクション 3 (Repr-Digest)、および
    • セクション 4 (Want-Content-Digest および Want-Repr-Digest)。

  • 表現データ整合性に固有の考慮事項。

    • セクション 3.1 (状態変更リクエスト)、
    • セクション 3.2 (Content-Location)、
    • 付録 A には、メッセージ交換における表現データの具体的な例が含まれています。
    • 付録 B および C には、メッセージ交換における Repr-Digest および Want-Repr-Digest フィールドの具体的な例が含まれています。

  • セクション 5 では、ハッシュアルゴリズムの考慮事項を提示し、将来のエントリの登録手順を定義します。

1.2. 概念の概要​

この文書で定義されている HTTP フィールドは、HTTP の整合性のために使用できます。送信者はハッシュアルゴリズムを選択し、HTTP メッセージに関連する入力からダイジェストを計算します。アルゴリズム識別子とダイジェストは HTTP フィールドで送信されます。受信者は、整合性の目的でダイジェストを検証できます。ハッシュアルゴリズムは、「HTTP ダイジェストフィールドのハッシュアルゴリズム (Hash Algorithms for HTTP Digest Fields)」レジストリに登録されています（セクション 7.2 を参照）。

ダイジェストを計算するデータの選択は、HTTP メッセージの使用例によって異なります。この文書では、HTTP 表現データと HTTP コンテンツに対して異なるフィールドを提供しています。

HTTP コンテンツバイトの単純なダイジェストが必要な使用例があります。Content-Digest リクエストおよびレスポンスヘッダーとトレーラーフィールドは、コンテンツ ([HTTP] のセクション 6.4) のダイジェストをサポートするように定義されています。セクション 2 を参照してください。

より高度な使用例のために、Repr-Digest リクエストおよびレスポンスヘッダーとトレーラーフィールド（セクション 3）が定義されています。これには、選択された表現データ ([HTTP] のセクション 8.1) にハッシュアルゴリズムを適用して計算されたダイジェスト値が含まれています。Repr-Digest を選択された表現に基づかせることで、メッセージコンテンツがリソースの表現と見なされるために何らかの操作を必要とする場合や、コンテンツがリソースの部分的な表現を伝達する場合（範囲リクエストなど、[HTTP] のセクション 14 を参照）の使用例に適用することが容易になります。

Content-Digest と Repr-Digest は、ハッシュアルゴリズムのアジリティをサポートしています。Want-Content-Digest および Want-Repr-Digest フィールドを使用すると、エンドポイントはそれぞれ Content-Digest および Repr-Digest への関心を表明し、いずれかのアルゴリズムの優先順位を表明できます。

Content-Digest と Repr-Digest は、まとめて「整合性フィールド (Integrity fields)」と呼ばれます。Want-Content-Digest と Want-Repr-Digest は、まとめて「整合性優先フィールド (Integrity preference fields)」と呼ばれます。

整合性フィールドは、Content-Encoding および Content-Type ヘッダーフィールドに関連付けられています。したがって、特定のリソースは、HTTP で転送される際に複数の異なるダイジェスト値を持つ場合があります。

整合性フィールドは、HTTP メッセージコンテンツまたは HTTP 表現に適用されます。HTTP メッセージまたはフィールドには適用されません。ただし、デジタル署名などのメタデータを保護する他のメカニズムと組み合わせて、HTTP 交換のフェーズ全体または一部を保護することができます。たとえば、HTTP メッセージ署名 [SIGNATURES] を使用して整合性フィールドに署名し、HTTP コンテンツまたは表現データのカバレッジを提供できます。

この仕様では、認証、認可、またはプライバシーの手段は定義されていません。

1.3. RFC 3230 の廃止​

[RFC3230] は、HTTP 整合性のための Digest および Want-Digest HTTP フィールドを定義しました。また、現在では HTTP セマンティクスとしてより一般的に定義および実装されている、選択された表現データ ([HTTP] のセクション 8.1) などの概念を説明するために、「インスタンス (instance)」および「インスタンス操作 (instance manipulation)」という用語を作り出しました。

経験上、[RFC3230] の実装では「インスタンス」の意味が一貫して解釈されておらず、相互運用性の問題につながっています。最も一般的な問題は、当初の意図通りに（現在で言う）表現データを使用するのではなく、（現在で言う）メッセージコンテンツを使用してダイジェストを計算するという間違いに関連しています。興味深いことに、メッセージコンテンツのダイジェストが一部の使用例で有益であることも時間が経つにつれて示されているため、[RFC3230] への不適合が意図的か意図的でないかを検出することは困難です。

Digest および Want-Digest の実装全体での潜在的な不整合と曖昧さに対処するために、この文書は [RFC3230] を廃止します。この文書で定義されている整合性フィールド（セクション 2 および 3）および整合性優先フィールド（セクション 4）は、現在の HTTP セマンティクスとよりよく整合しており、意図された使用法をより明確に表現する名前を持っています。

1.4. 表記上の規則​

この文書内のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、ここに示すようにすべて大文字で表示される場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。

この文書では、[RFC5234] で定義され、[RFC7405] で更新された拡張 BNF を使用します。これには、CR（キャリッジリターン）、LF（ラインフィード）、および CRLF (CR LF) のルールが含まれます。

この文書では、構文と解析を指定するために、[STRUCTURED-FIELDS] のセクション 3 の次の用語を使用します：ブール値 (Boolean)、バイトシーケンス (Byte Sequence)、辞書 (Dictionary)、整数 (Integer)、およびリスト (List)。

この文書内の定義「表現 (representation)」、「選択された表現 (selected representation)」、「表現データ (representation data)」、「表現メタデータ (representation metadata)」、「ユーザーエージェント (user agent)」、および「コンテンツ (content)」は、[HTTP] で説明されているように解釈されます。

この文書では、[FOLDING] で説明されている行折り返し戦略を使用します。

ハッシュアルゴリズム名は、定義文書で使用されている大文字と小文字の区別を尊重します（例：SHA-1、CRC32c）。

HTTP メッセージは、アルゴリズムキー (Algorithm Key)（アルゴリズム）を使用してハッシュアルゴリズムを示します。文書が散文でアルゴリズムキーを参照する場合は、引用符で囲まれます（例："sha"、"crc32c"）。

「チェックサム (checksum)」という用語は、バイトシーケンスにアルゴリズムを適用した出力を記述しますが、「ダイジェスト (digest)」は、フィールドに含まれる値に関連してのみ使用されます。

「整合性フィールド (Integrity fields)」は、Content-Digest と Repr-Digest の総称です。

「整合性優先フィールド (Integrity preference fields)」は、Want-Repr-Digest と Want-Content-Digest の総称です。

に最終更新