総合面接：HTTP 208 Already Reported はいつ使用すべきか、またその誤用をどのように防ぐか？

プロンプトと適用範囲

WebDAV サービスでは、複数のバインディングが同じリソースを指すことができます。クライアントが Depth infinity を指定した PROPFIND を送信し、サーバーが 1 つの 207 Multi-Status レスポンス内でそのリソースに繰り返し遭遇します。208 Already Reported、それを返すタイミング、レガシーなクライアントの処理方法、および 508 Loop Detected との違いについて説明してください。

これは RFC 5842 の WebDAV バインディング拡張です。208 は「すでに存在する」ことを表す汎用的な REST 成功コードではありません。

面接官がテストしていること

208 がスタンドアロンの HTTP レスポンスステータスではなく、207 Multi-Status レスポンス内のステータス行であることを識別できるか。
バインディングのエイリアス、リソースの同一性、および重複列挙を結び付けられるか。
すでに報告されたリソースと実際のバインディングループを区別し、508 を正しく使用できるか。
Depth の制限、クライアントの機能処理、XML パース、およびオブザーバビリティを設計できるか。

明確化のための質問

サービスは RFC 5842 のバインディングメソッドおよび DAV:resource-id を実装していますか？
クライアントは 208 を理解できますか、それとも基本的な WebDAV 207 レスポンスのみを理解しますか？
PROPFIND の Depth は 0、1、または infinity のいずれですか。また、どのようなサーバー制限が適用されますか？
重複はバインディング、シンボリックリンク、または実際の親子サイクルによって引き起こされていますか？
プロダクトはすべてのエイリアスをリストする必要がありますか、それとも各リソースを 1 回だけ報告すればよいですか？

30秒の回答

「208 は、主に WebDAV バインディングによって重複列挙が発生した場合に、同じ 207 Multi-Status レスポンス内ですでに報告されたリソースをマークします。私は安定したリソース識別子によって重複を排除し、最初の出現に対して完全な propstat を返し、以降のバインディングには 208 を使用します。安全に終了できないバインディングループは 508 です。208 を理解しないクライアントに対しては、Depth を制限するか、WebDAV コントラクト内でパース可能な 207 を返し、重複排除、深度、ループ、および切り捨ての理由を記録します。通常の REST の『すでに存在する』という結果に 208 を使用することは決してありません。」

ステップごとの設計

1. レスポンスレイヤーの確認

外部の HTTP レスポンスは通常 207 Multi-Status です。各レスポンスにはリソース URI と 1 つ以上の propstat 要素が含まれます。208 は関連する DAV プロパティレスポンス内のステータス行であり、バインディングのリソースがこの Multi-Status レスポンスですでに報告されていることを示します。外部の 207 を 208 で置き換えてはなりません。

2. リソースの同一性による重複排除

URI は必ずしもリソースの識別子ではありません。異なるバインディングが、1 つのリソースに対して異なる URI を公開する可能性があります。走査ごとの訪問済みセットには DAV:resource-id または安定した内部 ID を使用します。最初の遭遇時に完全なプロパティを出力し、それ以降のバインディングには各 URI の関係を保持しながら 208 を出力します。

text

PROPFIND Depth: infinity
  /alias-a -> resource R: full propstat
  /alias-b -> resource R: 208 Already Reported
  /child   -> resource C: full propstat

3. 208 を意図されたコンテキスト内に維持する

208 は、重複する 207 プロパティペイロードを節約し、バインディングの列挙が無制限に拡張するのを防ぎます。これは、データベースの挿入競合、冪等な再試行の成功、またはキャッシュヒットを意味するものではありません。通常の JSON API では、代わりに明示的な 200、201、204、または 409 のセマンティクスを選択する必要があります。

4. 508 Loop Detected の区別

走査によって、すでに完了したリソースへの 2 回目の参照ではなく、サイクルを形成するバインディング関係が見つかった場合は、再帰を停止して 508 Loop Detected を使用します。208 はリソースが以前に正常に報告されたことを意味し、508 は無限ループを回避するために処理が停止されたことを意味します。エイリアス、実際のサイクル、および深度制限を個別にテストします。

5. 互換性とリソース制限の処理

クライアントの 208 サポートをネゴシエートまたは観察します。古いクライアントの場合は、Depth infinity を制限するか、安全でないリクエストを拒否するか、WebDAV セマンティクスに違反することなくパース可能な propstat コンテンツを返します。悪意のあるバインディンググラフがサービスを枯渇させないように、ノード数、レスポンスバイト数、時間、および訪問済みセットのメモリを制限します。

6. 監視とリカバリ

リクエスト ID、Depth、訪問済みリソース数、208 カウント、508 カウント、切り捨て理由、レスポンスサイズ、およびクライアント機能を記録します。ファイルの内容や認証情報は決してログに記録しないでください。重複排除インデックスが失敗した場合は、無制限の再帰を出力するのではなく、明示的なエラーで安全に切り捨てます。同一性とループのデバッグ用に再現可能なバインディンググラフを保持します。

質の高い模範解答

「外部レスポンスは 207 Multi-Status のままであり、208 は同じリソースがすでに報告されたことを示すために propstat ステータス内に現れます。Depth infinity の PROPFIND では、リソースの同一性から訪問済みセットを構築します。最初のバインディングは完全なプロパティを返し、以降のエイリアスは URI を保持しながら 208 を返します。実際のサイクルは 508 で停止します。汎用 API の『すでに存在する』や再試行の結果に 208 を使用することはありません。古いクライアントには深度制限や安全な拒否を適用し、テレメトリではリソース、レスポンスサイズ、208、508、および切り捨てをカバーします。」

よくある間違い

HTTP レスポンス全体を 208 に設定する → 207 Multi-Status の構造が失われる → 関連する propstat ステータスに 208 を配置する。
URI をリソースキーとして使用する → エイリアスによって依然としてリソースが重複する → リソース ID によって重複を排除する。
すでに存在することに対して 208 を使用する → 汎用 REST クライアントが誤解する → 409 または明示的なビジネスレスポンスを使用する。
すべての重複を 508 として扱う → 通常のエイリアスがループのように見える → 報告済みリソースとサイクルを分離する。
Depth またはレスポンスの制限を設定しない → バインディンググラフがメモリを枯渇させる可能性がある → ノード、時間、バイト、および訪問済みセットのサイズを制限する。

フォローアップの質問と回答

208 エントリには依然として URI が必要ですか？

はい。クライアントがどの URI が走査されたかを認識できるように、そのバインディングのレスポンスを保持しますが、完全なプロパティペイロードは繰り返しません。XML は WebDAV Multi-Status のパースコントラクトに従う必要があります。

重複エントリを完全に削除しないのはなぜですか？

削除するとエイリアスが走査されたという事実が隠され、サーバーの記載漏れのように見える可能性があります。208 は重複するプロパティデータを回避しながら、走査の証拠を保持します。

サーバーはいつ Depth infinity を拒否すべきですか？

クライアントが 208 をパースできない場合、バインディンググラフがリソース制限を超える場合、または信頼できる訪問済みセットを構築できない場合に、拒否または上限を設定します。不完全な出力や無制限の再帰よりも、制限されたレスポンスの方が安全です。