要約

  • unsupported_algorithms、invalid_digests、mismatched_digests は診断を豊かにする任意の拡張であり、省略に特別な否定的意味はない。
  • 応答が一つの問題だけを示しても、他の問題が存在しない、最初の項目が最優先である、あるいは要求を安全に再送できるとは証明されない。

クライアントは 400 応答を受け取った。問題型は digest-mismatched-values だったが、期待していた詳細配列はなかった。実装は欠けたフィールドを other_failures=false として保存し、「単一の一時的不一致」と判定した。要求は自動的に再送された。

しかしサーバーが表明したのは、詳細を返さなかったということだけだった。ほかの診断が存在しないとは表明していない。

この差は、機械可読なエラー設計で最も失われやすい。スキーマがあると、受信側は各欄を完全な質問票のように扱いたくなる。だが HTTP Problem Types for Digest Fields の revision 06 は、クライアントが問題型フィールドの存在に一般には依存できず、拡張メンバーの省略には特別な意味がないとする。未知と否定は別の値である。

対象文書は 2026 年 6 月 24 日付で、12 月 26 日に失効する HTTPAPI ワーキンググループの Internet-Draft である。2026 年 10 月 2 日の Datatracker では RFC Editor queue の Awaiting First Editor にあり、担当 Area Director は Mike Bishop、IANA は必要な処理を RFC-Ed-Ack としていた。Standards Track の Proposed Standard を目指すが、RFC 番号はまだない。文書工程が進んだことと、製品が同じ開示方針で実装したことは別である。

拡張は診断能力であり、完全性保証ではない

草案は三つの問題型を定義する。digest-unsupported-algorithms は、対象フィールドで提示されたアルゴリズムを検証者が扱えない場合に使う。unsupported_algorithms の項目はアルゴリズムとヘッダーを示す。対応する preference field により、サーバーが扱える選択肢や順序を示すこともできる。

digest-invalid-values は、宣言されたアルゴリズムから生成されたはずのない値を扱う。たとえば SHA-512 として成立しない長さである。invalid_digests にはアルゴリズム、ヘッダー、人間向けの理由を含められる。ただし Structured Fields の構文解析失敗とは別である。構文が読めない段階では、値の形を検査する材料がまだない。

digest-mismatched-values は、比較できる形の提供値とサーバー計算値が一致しない場合である。mismatched_digests はアルゴリズム、提供された digest、ヘッダーを示せる。サーバー計算値は oracle 化を避けるため返さない。

三つの配列は、あると調査を速くする。しかし欠けていても「該当なし」とはならない。サーバーはセキュリティ上の配慮、実装差、情報量制限、一般的なエラー方針によって詳細を省くことがある。受信側が空欄を false で埋めれば、開示されなかった状態を検査済み状態に書き換える。

複数項目の順序も命令ではない

一つの要求には複数の Digest field や preference field が入り得る。そのため、同種の問題が複数項目として現れることがある。配列の先頭は root cause でも、修復優先度でもない。草案は配列順を意思決定権として定義していない。

先頭だけを修正して再送するクライアントは、二番目の既知問題に順番に衝突する。結果として、最初から一つの応答で得られた情報を複数回の要求と副作用へ展開してしまう。さらに応答詳細が任意なら、二番目が存在するかどうかも完全には分からない。

安全な状態機械は、受け取った項目を「観測済み」、明示的な否定を「該当なし」、省略を「未知」と保存する。修復候補を作ることはできるが、その候補を実行するには別の再試行権限が必要になる。

ヘッダーを落とすと観測層を失う

各項目に header が含まれるのは、フィールド名が計算範囲を示すからである。RFC 9530 の Content-Digest は HTTP content、Repr-Digest は selected representation を対象とする。content coding や変換によってバイト列は異なり得る。別の現行 Internet-Draft である Unencoded-Digest は未符号化 content の範囲を提案しており、研究時点では RFC ではない。

「SHA-256 mismatch」だけを保存しても、どの現実層が不一致だったかは残らない。同じアルゴリズムが異なる場所で正しく計算され、違う結果になることはある。値の正しさと範囲の一致を分けなければならない。

省略と範囲喪失が重なると、危険は増す。詳細配列がないから問題は一つ、ヘッダーがないから計算対象は同じ、と二段階で推測すると、応答が一度も述べていない完全な因果物語ができあがる。

Problem Details は取引台帳ではない

RFC 9457 の Problem Details は、問題の型と補足情報を運ぶ。JSON の status は存在しても advisory であり、中間装置が実際の HTTP status を変えれば一致しない場合がある。本文は HTTP メソッドやアプリケーション結果を再定義しない。

Digest 問題草案が推奨する status は三型とも 400 である。クライアントが 400 を受け取ったという事実は、分散経路のどこにも副作用がなかったという証明ではない。CDN、ゲートウェイ、監査、キュー、オリジンが異なる順序で処理する構成では、ある地点の拒否より前に別の地点が記録や予約を作る可能性がある。

RFC 9110 は再試行の権限を別に置く。冪等なメソッドは接続失敗後の自動再試行に適する。一方、非冪等要求は、実際の意味が冪等だと分かるか、最初の要求が適用されなかったと検出できない限り、自動再試行すべきではない。プロキシは非冪等要求を自動再試行してはならず、失敗した自動再試行をさらに自動で繰り返すべきでもない。

草案の例には PUT と POST がある。問題型は POST を冪等に変えない。idempotency key、取引 ID、条件付き要求、永続的なアプリケーション receipt が、再送可否を判断する。診断配列の有無はその代わりにならない。

詳細を返さないことにも安全上の理由がある

不一致時にサーバー計算 digest を返さないのは oracle を防ぐためである。提供値の回示、対応アルゴリズム、細かな理由も、サーバー実装や中間装置の存在を fingerprint する材料になり得る。運用者はリスクに応じて一般的な問題を返す選択をする。

受信側が詳細を必須とみなすと、サーバーに過剰開示を迫るか、欠落を誤って成功扱いする。どちらも悪い。契約は「開示された情報はこの範囲で有効、開示されない状態は未知」と表現すべきである。

提供された digest 自体も、ログ、チケット、外部分析基盤へ無制限に複製すべきではない。調査に足りる安全な fingerprint と、アクセス制御された原証拠を分けることで、診断価値と漏えい面を両立できる。

未知を保存する最小仕様

Heng Lu の現実層では、Digest と問題型は象徴的な主張である。パーサーと検証者は実行状態を持つ。再送は新たな行為であり、アプリケーション commit と利用者結果は後の観測である。任意フィールドの欠落が上位層の結果を決めることはできない。

Minimum Initial Specification は、操作 ID、メソッド、対象、試行番号、冪等性根拠、Digest header、アルゴリズム、提供値の保護 fingerprint、検証地点、実際の status、問題型、各拡張の三値状態、応答由来、アプリケーション receipt を残せばよい。全世界を記録せずとも、未知を false に変えないだけで大きな誤りを防げる。

Running-Code Primacy の試験では、拡張を一つずつ省略し、複数項目の順序を入れ替え、一般問題へ縮退し、異なるヘッダーを混在させる。最初のアプリケーション結果が不明な POST も再送させ、停止できるか確認する。期待される出力は、空欄を埋めた整然とした表ではなく、証拠の限界を正確に示す表である。

機械可読性は完全性と同義ではない。返ってきた事実を正確に使うためには、返ってこなかった事実を創作しないことが必要だ。

出典