プロンプトとスコープ
レガシーなクライアントが HTTP 拡張宣言を送信しており、一部のリクエストではサーバーがその拡張を理解している必要があります。ゲートウェイがリクエストを転送しても、オリジンがそれをサポートしていない場合があります。510 Not Extended を説明し、501 および 400 と比較した上で、互換性、オブザーバビリティ、移行、およびロールバックの手順を提案してください。
RFC 2774 はこの拡張フレームワークを「Historic（歴史的）」と分類しています。この質問はプロトコルのセマンティクスをテストするものであり、最新のパブリック API で 510 が一般的に導入されていることを意味するものではありません。
面接官がテストしていること
- 510 が通常のビジネスロジックのバリデーションではなく、満たされていない HTTP 拡張の要件に関するものであることを理解しているか。
- 拡張を満たせないオリジン（510）と、サポートされていないメソッド（501）を区別できるか。
- 510 を普遍的なエラーフォーマットとして扱うのではなく、RFC 2774 の歴史的ステータスを認識しているか。
- 設計において、プロキシ、キャッシュ、互換性、および移行の根拠を統合して網羅できているか。
明確化のための質問
- リクエストは実際に必須の RFC 2774 拡張を宣言していますか？それとも単に未知のビジネスヘッダーが含まれているだけですか？
- どのホップ（クライアント、プロキシ、ゲートウェイ、またはオリジン）が拡張宣言を解釈できますか？
- クライアントはアップグレード可能ですか？また、安定した代替リクエストフォーマットは存在しますか？
- ミドルボックスが 510 レスポンスを書き換え、キャッシュし、またはラップする可能性はありますか？
- 移行では読み取り操作と書き込み操作の両方をサポートする必要がありますか？
30秒での回答
「510 は、サーバーが満たすことのできない必須の HTTP 拡張に対する RFC 2774 のレスポンスです。501 はサーバーがリクエストされたメソッドをサポートしていないことを意味し、400 はリクエストの一般的な構文またはセマンティクスが無効であることを意味します。RFC 2774 は Historic であるため、まずトラフィックがこのフレームワークを使用していることを証明し、次に 510 をレガシー互換性のシグナルとして維持します。すなわち、機密情報を含まない診断可能なエラーを返し、拡張識別子とパスを記録し、クライアントをバージョニングされた API コントラクトへと移行させます。未知のビジネスヘッダーや通常のバリデーション失敗を 510 にすべきではありません。」
ステップバイステップの設計
1. 拡張宣言の検証
RFC 2774 のシナリオは、単に見慣れないヘッダーを目にするよりも具体的です。クライアントは拡張とその識別子を宣言し、受信者がそれを理解することを必須とすることができます。510 が該当すると判断する前に、生のリクエスト、プロキシの転送ログ、およびオリジンのログで宣言を確認します。
2. 隣接するステータスコードの分離
510 は要求された拡張を満たせないことを意味します。501 はリクエストを処理するために必要なメソッドがサーバーに実装されていないことを意味します。400 は一般的なセマンティクスにおいてリクエストを解析または処理できないことを意味します。認証、認可、スロットリング、およびビジネスルールには、それぞれのステータスコードと安定したエラーコードを割り当てるべきです。
3. 診断可能なレスポンスの設計
安定したエラータイプ、リクエスト ID、拡張識別子の安全な要約、および移行ドキュメントを返します。検証されていない URI、内部コンポーネント名、または機密性の高いリクエストデータをエコーバックしないでください。共通のエラーフォーマットが application/problem+json の場合、510 でプロトコルの原因を特定し、ビジネスの詳細は拡張メンバーに含めます。
HTTP/1.1 510 Not Extended
Content-Type: application/problem+json
Cache-Control: no-store
{"type":"https://api.example/problems/unsupported-extension","title":"Required extension is unsupported","status":510,"instance":"req-7f2"}4. プロキシとキャッシングの処理
プロキシが拡張宣言を削除していないか、510 を 400 に書き換えていないか、またはキャッシュレイヤーでエラーを再利用していないかをテストします。アイデンティティ、機能、またはテナント情報に依存するレスポンスには、保守的なキャッシングを使用します。機密性の高いリクエスト全体を保存することなく、パス、拡張識別子、プロキシバージョン、およびオリジンの結果を記録します。
5. レガシー移行の計画
クライアントバージョンおよび拡張識別子ごとに障害を測定します。拡張に依存しないバージョニングされたリクエストフォーマットを提供し、ドキュメントおよび SDK で切り替え期日を公開します。移行期間中は、明示的な機能ネゴシエーションとロールバック条件を備えた上で、新旧両方のフォーマットを受け入れます。アップグレードのカバレッジしきい値が満たされた後にのみ、古いパスを廃止します。
6. 検証とロールバックの定義
実際のプロキシチェーンとコントラクトテストを使用して、4 つのパス（サポートされている拡張、欠落している拡張、ミドルボックスによって除去された拡張、通常の未知のヘッダー）をテストします。クライアントのアップグレードと並行して、510、501、および 400 の比率を監視します。構成のリリース後に 510 が急増した場合は、まず互換性パスを復元してから解析処理を修正します。存在しない拡張へのサポートは、オリジンへのリトライだけでは追加できません。
模範的な質の高い回答
「まずパケットキャプチャとプロキシログを確認して、必須の RFC 2774 拡張宣言が存在することを証明します。その拡張を満たせないオリジンのみが 510 を発行すべきです。サポートされていないメソッドは 501 であり、一般的に無効なリクエストは 400 です。RFC 2774 は Historic であるため、510 はレガシー互換性のみに限定し、安定したエラータイプ、リクエスト ID、移行ドキュメントを返し、保守的なキャッシングを使用し、拡張、プロキシ、およびクライアントのバージョンを記録します。その後、拡張に依存しないバージョニングされた API を提供し、コントラクトテストで転送と書き換えを検証し、アップグレードのカバレッジに基づいて古いパスを廃止し、ロールバックスイッチを保持します。」
よくある間違い
- 任意の未知のヘッダーに対して 510 を返す → 必須の拡張が証明されていない → まず拡張宣言と要件をパースする。
- 510 を 501 として扱う → 拡張の失敗とメソッドの不在は異なる → RFC のシナリオとメソッドのセマンティクスを別々に適用する。
- 510 を長期的なパブリック API の規約にする → エコシステムの互換性が脆弱になる → Historic な依存関係としてマークし、バージョンごとに移行する。
- エラーの共有キャッシュを許可する → 1 つのクライアントの機能結果が他に影響を与える → アイデンティティとネゴシエーションデータに従ってキャッシュポリシーを設定する。
- 古いリクエストをリトライするだけにする → リトライによってサポートされていない拡張のサポートが生成されることはない → アップグレード、ダウングレード、または代替フォーマットを使用する。
フォローアップの質問と回答
510 と 501 の違いを一文で表すと？
510 はリクエストによって宣言された満たすことができない HTTP 拡張に関するものであり、501 はリクエストされたメソッドまたはそれを処理するために必要な実装をサポートしていないサーバーに関するものです。どちらも通常のビジネスエラーコードの代わりにはなりません。
未知のビジネスヘッダーで 510 を生成すべきか？
直接的には生成すべきではありません。未知のヘッダーは無視されるか、ビジネスコントラクトによって拒否されるか、または 400 として処理される可能性があります。510 は、リクエストがサーバーの満たせない RFC 2774 形式の拡張を明示的に要求している場合にのみセマンティクス上の根拠を持ちます。
なぜ RFC 2774 の Historic ステータスが重要なのか？
これは実装やクライアントエコシステムが限られており、相互運用性のリスクが高いことを示しています。優れた面接の回答では、すべての最新 HTTP スタックがこのフレームワークをサポートしていると仮定するのではなく、510 をレガシープロトコルの境界として扱い、オブザーバビリティ、コントラクトテスト、およびバージョニングされた移行によってそのリスクを制御します。