プロンプトと適用範囲
WebDAV クライアントがリソースへのアクセス中に HTTP 508 Loop Detected を受信します。システムにはバインディング、リライトルール、および複数のプロキシが存在します。プロトコルの意味、ループを証明する方法、クライアントのフォールバック、およびリトライストームを防ぐ方法を説明してください。
面接官が評価するポイント
- 508 が一般的なタイムアウトではなく、WebDAV バインディング拡張に由来することを理解しているか。
- サーバーが検出したループと、通常の上流 5xx エラーを区別できるか。
- リクエストチェーン、バインディンググラフ、および検出バジェットを記録できるか。
- 冪等、再試行不可、および人間による修復が必要な境界を定義できるか。
- 内部トポロジーを露出させずに監査証跡を保持できるか。
最初に確認すべき明確化事項
メソッド、DAV バインディングの種類、ループがバインディングにあるのかプロキシのリライトにあるのか、再試行ミドルウェア、診断用識別子、およびクライアントが読み取り専用かどうかを確認します。不明な場合は、トラバーサルがすでに訪問したノードに戻ると仮定します。
30秒の回答フレームワーク
508 は、サーバーが WebDAV バインディング操作の処理中にループを検出し、リクエストを完了できないことを意味します。request id を使用してバインディングエッジ、プロキシホップ、および訪問済みノードの有向グラフを構築し、単一のタイムアウトではなく循環を証明します。やみくもに再試行しないでください。同一のトポロジーであればフェイルファスト（即時失敗）させ、オペレーターに修復を促す必要があります。トラバーサルに上限を設け、非機密の診断用 id を返します。
ステップごとの詳細解説
1. プロトコルの意味を定義する
RFC 5842 は、WebDAV バインディング操作の完了中にループが検出された場合に対して 508 を定義しています。これはクライアントがネットワークを失ったことを意味するものではなく、すべての 5xx が再試行可能になるわけでもありません。
2. バインディングとプロキシのグラフを描画する
各リソースまたはバインディングノードに内部 id を付与し、エッジの送信元、宛先、request id、およびプロキシホップを記録します。トラバーサル中に訪問済みセットを維持します。ノードを再度検出することで循環が証明されます。深さ制限への到達は別個の保護的障害であり、誤って 508 とラベル付けされるべきではありません。
3. 上流の障害を切り分ける
プロキシはバックエンドの 508 をラップしたり、独自のリライトサイクルを作成したりすることがあります。エッジのレスポンスのみを調査するのではなく、各ホップで trace id、元のステータス、および Via 情報を保持します。
4. 再試行とフォールバックを設計する
同じ設定を再試行してもトポロジーの循環は解消されないため、指数バックオフによる再試行に入るのではなく、フェイルファストさせます。設定の修正、バージョン変更、または明示的なコントロールプレーンの更新後にのみ、バジェット制限付きの再試行を許可します。製品のセマンティクスが許す場合は、バインディングをたどらずに読み取り専用のメタデータにフォールバックします。
5. リソースと機密詳細を制限する
最大ノード数、時間、およびレスポンスサイズを設定します。内部ホスト名や完全なバインディンググラフではなく、対処可能な修復のヒントと correlation id を返します。ハッシュ化されたノード、エッジの種類、およびサイクル長を監査レコードに保持します。
6. 監視と修復
508 の発生率、テナントおよびバインディングタイプの分布、サイクル長、トラバーサル時間、再試行回数、および修復にかかった時間を追跡します。設定を書き込む前に静的なサイクルチェックを実行します。プロキシをスケーリングするだけでなく、不正なバージョンを凍結してバインディングをロールバックします。
7. テストと受け入れ
自己循環、2ノード循環、プロキシ間循環、深い非巡回グラフ、同時更新、古いキャッシュ、および部分的なノード障害をテストします。受け入れ基準には、安定したステータス、リトライストームの不在、追跡可能な診断情報、機密漏洩の防止、および修復後のリクエストの成功が含まれます。
高品質な回答サンプル
508 は WebDAV の Loop Detected ステータスであり、トラバーサルが訪問済みのバインディングノードに戻ったことを意味します。request id を使用してリソースバインディング、リライト、およびプロキシホップのグラフを構築し、訪問済みセットを使用して実際の循環と深さガードを区別します。エッジプロキシが原因を隠蔽しないよう、各ホップで元のステータスとトレースデータを保持します。
同じトポロジーでは再度失敗するため、クライアントは指数関数的に再試行するのではなくフェイルファストします。不正なバインディングを凍結し、サイクルチェックを検証し、修復後に段階的に復元します。ノード数と時間に上限を設け、correlation id のみを返し、508 率、サイクル長、トラバーサル時間、修復時間を監視します。自己循環、プロキシ間循環、深い非巡回グラフ、同時変更、および古いキャッシュをテストします。
よくある間違い
- 508 をタイムアウトやあらゆる 5xx の同義語として扱うこと。
- 循環を証明することなく、深さ制限による障害を 508 と呼ぶこと。
- 同じバインディングトポロジーに対して無制限に再試行すること。
- エッジのステータスのみをログに記録し、プロキシのコンテキストを失うこと。
- 完全な内部バインディンググラフを返してしまうこと。
- 設定書き込み前に循環をチェックせず、プロキシのスケーリングだけで対処しようとすること。
フォローアップの質問と回答
フォローアップ 1：深さ制限は自動的に 508 になりますか？
いいえ。それは保護的な制限です。循環は、トラバーサルがノードを再訪した場合にのみ証明されます。内部理由は区別可能なままである必要があります。
フォローアップ 2：クライアントはいつ再試行できますか？
設定の修正、コントロールプレーンのバージョン変更、または明示的な一時的シグナルがあった後で、かつバジェットの範囲内でのみ再試行できます。変更のないトポロジーはフェイルファストすべきです。
フォローアップ 3：トポロジーの漏洩をどのように防ぎますか？
修復のヒントと correlation id を返します。ハッシュ化されたノードとエッジタイプをログに保存し、グラフは制御された内部ツールを通じてのみ開示します。
フォローアップ 4：プロキシが 508 を 502 に変更した場合はどうしますか？
ホップごとのトレース、Via、および元のステータスを保持し、エッジコードのみから原因を推測するのではなく、エンドツーエンドでそれらをマッピングします。