プロンプトと適用範囲
WebDAV リソースは、バインディングを通じて複数のパスに現れることがあります。そのため、再帰的なコレクショントラバーサルは同じリソースを再訪問したり、循環を無限にたどったりする可能性があります。RFC 5842 は、同じ multistatus レスポンスですでに報告されたメンバーに対して 208 Already Reported を定義し、ループに遭遇して処理が終了した場合に対して 508 Loop Detected を定義しています。
面接官が見ているポイント
- 508 を一般的なゲートウェイエラーとして扱うのではなく、WebDAV の文脈に位置づけているか。
- すでに報告されたメンバーに対する 208 と、終了した操作に対する 508 を区別できているか。
- 深度、ノード数、時間、およびレスポンスバイト数が強制可能なバジェットになっているか。
- クライアントの動作が冪等であり、可観測性があり、無限リトライが発生しないようになっているか。
明確化のための質問
- メソッドは PROPFIND で、Depth は infinity に設定されていますか？
- リソースは DAV バインディングをサポートしており、クライアントは 208 を理解できますか？
- サーバーはツリー全体、制限された結果、または有限の深さのみを返すべきですか？
- コレクションはマルチテナント（cross-tenant）にまたがるものですか？また、どのプロパティを開示できますか？
30秒での回答
まず、通常の HTTP リダイレクトではなく WebDAV バインディングの循環であることを確認します。トラバーサル中は安定したリソース ID を追跡し、深さ、ノード数、時間、レスポンスバイト数のバジェットを強制します。クライアントが 208 を理解できる場合、すでに報告されたメンバーはそのように表現できます。トラバーサルがアクティブな再帰スタックに戻り、安全に完了できない場合、サーバーは 508 と安定したエラーボディを返して終了します。クライアントは同じ無限深度リクエストを盲目的にリトライしてはならず、深さを減らすかバインディングの修復を要求する必要があります。
詳細な解説
1. 508 の境界を定義する
508 は、無限深度セマンティクスを処理中にループに遭遇したため、サーバーが WebDAV 操作を終了したことを意味します。ディスクフル、アップストリームのタイムアウト、またはあらゆる再帰的障害に対する一般的なコードではありません。エラーボディには安定したコードとリクエスト ID を含めることができますが、他のテナントのパスや内部トポロジを公開してはなりません。
2. バインディングの同一性を追跡する
トラバーサル中は、現在の URL のみを比較するのではなく、DAV の resource-id または別の安定したリソース ID を使用します。1つのリソースが複数のパスを持つことができるため、URL のみの重複排除ではエイリアスを見逃します。安定した ID を使用することで、有効なエイリアスを循環として扱うことなく重複メンバーを検出できます。
3. 208 か 508 かを選択する
クライアントとレスポンスのセマンティクスが許す場合、同じ multistatus 結果内にすでに存在するメンバーは 208 としてマークし、到達可能な他のメンバーの処理を継続できます。トラバーサルがアクティブな再帰スタック内のリソースに戻り、操作を安全に継続できない場合は、停止して 508 を返します。それぞれの意味は「すでに報告済み」と「ループのため終了」です。
4. リソースバジェットを強制する
非循環グラフであっても、最大深度、ユニークノード数、再帰スタック、レスポンスバイト数、および実経過時間（wall-clock time）の制限が必要です。バジェットが枯渇した場合は、安定したアプリケーションエラーまたは制限付き結果ポリシーを使用し、その理由を記録します。巨大なコレクションが無制限に CPU、メモリ、またはネットワーク帯域を消費しないようにしてください。
5. クライアントの回復を設計する
508 を受け取った後、クライアントはリクエスト ID とリソースコンテキストを保持し、同じ無限深度リクエストの自動リトライを停止する必要があります。有限の深さを使用するか、セグメント化された読み取りを行うか、管理者がバインディングを修復するのを待つことができます。Retry-After の値が提供されている場合でも、それは循環が解消されたことの証明にはなりません。
6. 並行性とキャッシュ
同一グラフの並行トラバーサルには、リクエストごとのバジェットとキャンセル処理が依然として必要です。キャッシュによってプロパティの読み取りを減らすことはできますが、認可をバイパスしたり、あるテナントのグラフを別のテナントに再利用したりすることはできません。循環が修復された後は、バージョンまたはチェンジトークンによって影響を受けるキャッシュとサマリーを無効化します。
7. 検証とオブザーバビリティ
自己バインディング、2ノードの循環、エイリアス、有限および無限の深さ、208 を理解しないクライアント、バジェットの枯渇、キャンセルの競合、および権限の変更をテストします。検出された循環、ユニークノード数、トラバーサル時間、レスポンスバイト数、508 率、208 率、およびリトライをテナントごとにセグメント化して監視します。
模範解答
508 は、循環を発見した後に WebDAV バインディングのトラバーサルを終了したことによる明示的な結果です。安定したリソース ID を使用してアクティブな再帰スタックと報告済みセットを維持します。すでに報告されたメンバーは、クライアントがサポートしている場合に 208 を使用でき、アクティブなスタックに戻った場合は 508 を生成します。各リクエストには深さ、ノード数、時間、バイト数のバジェットがあり、エラーボディには安定したコードとリクエスト ID のみが含まれます。クライアントは同じ無限深度リクエストのリトライを停止し、制限付きトラバーサルまたはバインディング修復に切り替えます。負荷テストでは循環、エイリアス、権限、キャンセルをカバーし、循環、バジェット、リトライのメトリクスを監視します。
よくある間違い
- 508 を単なる 5xx として扱う → クライアントが的を絞った修正を選択できない → バインディングループのコンテキストで使用する。
- URL で重複排除する → エイリアスが見逃されるか誤分類される → 安定したリソース ID を使用する。
- 208 をループエラーとして扱う → 報告済みメンバーが終了と混同される → 208 はメンバーがすでに報告されたことを意味する。
- 508 を無限にリトライする → ディレクトリの問題がリソースを消費し続ける → 深さを減らすかバインディングを修復する。
フォローアップの質問
208 と 508 は同じレスポンスに含まれることがありますか？
はい。一部のメンバーはすでに報告されているため 208 とマークされる場合があり、その後の循環によって操作全体が 508 で終了することがあります。レスポンス構造は WebDAV multistatus のセマンティクスに従う必要があります。
再帰深度の制限だけで十分ですか？
いいえ。浅くて横に広いコレクションであっても、多くのノードと大きなレスポンスを生成する可能性があるため、ユニークノード数、バイト数、CPU、および実経過時間も制限してください。
リバースプロキシは 508 を 500 に書き換えるべきですか？
通常は書き換えるべきではありません。ステータスと安定したエラーフィールドを保持してください。外部の契約でマッピングが必要な場合は、元の原因をログに残し、クライアントがリトライを停止するようにしてください。
修正後もエイリアスが機能していることをどのように証明しますか？
共有バインディングを持つ非循環グラフをテストします。複数のパスを通じて到達する同一のリソース ID は 208 または同等の重複排除を生成し、認可はパスごとに個別にチェックされたままである必要があります。