プロンプトとコンテキスト
キャッシュゲートウェイが Warning: 110 - "Response is stale" および Warning: 111 - "Revalidation failed" を追加しています。ブラウザやダウンストリームサービスはこれらのフィールドを一貫して表示せず、新しい標準でも推奨されなくなっています。歴史的なセマンティクス、キャッシュ検証の境界、代替フィールド、および損失のない移行について説明してください。
この質問は、バックエンド、ゲートウェイ、CDN、およびプラットフォームの面接に適しています。重要なのは、ある非推奨ヘッダーを別の自由形式のヘッダーに置き換えるのではなく、プロトコルメタデータ、ユーザーエラー、内部の可観測性を分離することです。
面接官がテストしていること
優れた回答では、Warning がメッセージの問題を記述できたこと、およびキャッシュ関連の 1xx 警告は検証が成功した後に削除できるものであったことを説明します。また、このフィールドは広く生成されたり表面化されたりしなかったこと、およびその情報の一部は Age などのフィールドから推測できるため非推奨になったことにも言及します。候補者は、自由形式のクライアント契約の代わりに、Cache-Control、Date、Age、バリデータ、ステータスコード、および構造化されたメトリクスを使用する必要があります。
最初に確認すべき明確化のための質問
- Warning はオリジン、共有キャッシュ、エッジゲートウェイのどこで生成されていますか？また、プロキシ層は複数存在しますか？
- 110 と 111 は診断専用ですか、それともクライアントがこれらに基づいてビジネスロジックの動作を変更していますか？
- レスポンスには
Date、Age、Cache-Control、ETag、Last-Modifiedが含まれていますか？ - どのレガシー・クライアントをサポートする必要があり、システムは一時的に二重書き込み（デュアルライト）を実行できますか？
- 「fresh（新鮮）」、「stale（古延）」、「revalidation failed（再検証失敗）」を必要としているのは誰ですか：ユーザー、ビジネスロジック、それとも運用担当者ですか？
30秒の回答フレームワーク
「私は Warning を、安定したユーザーエラーの契約ではなく、歴史的なキャッシュ診断として扱います。110 はステール（古い）レスポンスを、111 は再検証の失敗を示していましたが、このフィールドは非推奨であり、自由形式のテキストには適していません。コンシューマーとプロキシ層を棚卸しし、事実を Cache-Control、Date、Age、バリデータ、および構造化メトリクスで表現し、期間限定の互換性ウィンドウでのみ二重書き込みを行い、クライアントの挙動を観測した後に Warning を削除します。キャッシュヒット率、ステール配信率、再検証失敗率、エラーバジェットのメトリクスによって移行を検証します。」
ステップごとの詳細な回答
ステップ 1: Warning の歴史的役割を振り返る
Warning は、3桁のコード、生成エージェント、およびテキストを含むリクエストおよびレスポンスヘッダーでした。キャッシュ関連の 110 と 111 はステールレスポンスと再検証失敗を表していました。これらは HTTP ステータスコードではなく、4xx や 5xx を意味するものではありませんでした。複数のプロキシがフィールドを追加できるため、自由形式テキストのソースと信頼性は不安定でした。
ステップ 2: なぜ移行が必要なのかを説明する
MDN は、Warning が広く生成・利用されず、関連標準がこの一般的な警告メカニズムをもはや推奨していないため、非推奨とマークしています。これに依存するとキャッシュ診断が不安定なテキストに縛られ、プロキシによる重複、順序変更、またはフィルタリングの把握が困難になります。まず、どのクライアントもこれをビジネスシグナルとして扱っていないことを証明します。
ステップ 3: 標準キャッシュフィールドで事実を表現する
Date はレスポンス生成時刻を特定し、Age は共有キャッシュ内の滞留時間を概算します。Cache-Control は鮮度と再検証の要件を定義し、ETag または Last-Modified は条件付きリクエストをサポートします。これらが一体となってキャッシュ状態を記述します。独自の X-Warning 文字列は代替にはなりません。また、異なるリクエストに対する表現が混ざらないよう、オリジンは Vary を正しく設定する必要があります。
ステップ 4: 診断を可観測性へ移行する
ゲートウェイは、cache_status=stale、revalidation=failed、upstream=timeout、キャッシュ層、トレース ID などの構造化イベントを記録する必要があります。ログでは機密性の高い URL クエリ値を避け、メトリクスはルート、キャッシュキーファミリー、アップストリームエラークラスごとに集計する必要があります。レスポンスにはユーザーに関連する状態のみを含め、運用上の詳細は制御されたシステム内に保持します。
ステップ 5: 互換性のための二重書き込みウィンドウを設計する
まずはシャドウトラフィックや小規模なルートで Warning の消費を停止し、SDK、スクリプト、プロキシ規則の依存関係を確認します。レガシークライアントが存在する場合は、代替フィールドやアップグレードガイドを公開する間、Warning を一時的に維持します。代替フィールドには、任意のテキストをコピーするのではなく、安定した enum とバージョン管理された契約が必要です。二重書き込みには明確な終了期日を設定します。
ステップ 6: 階層化キャッシュと検証失敗を処理する
再検証の失敗は、必ずしもオリジンがダウンしていることを意味するわけではありません。タイムアウト、拒否された条件付きリクエスト、またはアップストリームの 5xx である可能性があります。ステールコンテンツを配信するか、エラーを返すか、stale-if-error ポリシーを適用するかを決定し、その理由を記録します。Warning の削除によってステール配信が隠蔽されたり、無限リトライが発生したりしてはなりません。
ステップ 7: 103 Early Hints とキャッシュ警告を分離する
103 Early Hints は最終レスポンスに先行し、主に preconnect や preload のための Link を通じて可能性の高いリソースを示唆します。これはキャッシュの鮮度や再検証の失敗を報告するものではなく、Age や Cache-Control を置き換えるものでもありません。すべてのヒントを Warning として扱うのではなく、各フィールドのタイミング、コンシューマー、および失敗のセマンティクスを明確にします。
ステップ 8: 段階的に削除して検証する
移行の前後で、Warning の読み取り、キャッシュヒット率、ステール配信比率、条件付きリクエストの成功率、オリジンエラー、P95 レイテンシ、およびクライアントエラーを比較します。1 つのキャッシュ層で生成を無効化し、チェーン全体に展開した後、レガシークライアントが整理されたらコード、ドキュメント、アラートを削除します。ロールバックスイッチは互換性出力のみを復元するべきであり、Warning に対するビジネス依存を復活させてはなりません。
トレードオフと境界
Warning を維持することは短期的な互換性コストが低いものの、不安定な契約と曖昧なトラブルシューティングを長引かせます。即座に削除するとプロトコルのノイズは減少しますが、レガシースクリプトが破損する可能性があります。最も安全なパスは、実際の依存関係を観測した上で、標準のキャッシュフィールドと構造化された可観測性へとニーズを移行することです。
Age をオリジン生成時刻と解釈したり、Cache-Control: no-cache を「キャッシュ不可」と解釈したりしないでください（後者は再利用前に再検証を要求します）。キャッシュポリシー、バリデータ、およびエラーレスポンスは、ビジネスで許容される鮮度ウィンドウを考慮して設計する必要があります。
ロールアウト計画とエビデンス
第 1 週には、エッジ、共有キャッシュ、およびクライアントから Warning の読み取りパスをエクスポートし、ルートおよびキャッシュ層ごとのベースラインを確立します。次に、重要度の低い依存関係のルートで構造化メトリクスの二重書き込みを行い、Age、条件付きリクエスト、およびエラー率を比較します。最後に、ワンクリックで互換性出力を戻せるスイッチを維持しながら、Warning を層ごとに無効化します。
受け入れ条件として、本番クライアントが Warning を読み取っていないこと、キャッシュヒットおよび再検証の成功率が低下していないこと、stale-if-error イベントが説明可能であること、ログとメトリクスがトレース ID によって関連付けられていること、およびドキュメント、SDK、アラートが更新されていることが求められます。
よくある落とし穴とフォローアップ
110 を 4xx や 5xx として扱う
110 は歴史的な Warning コードであり、レスポンスステータスではありません。ビジネスエラーはステータスおよびレスポンス契約に属し、キャッシュ診断はメトリクスに属します。
X-Warning で問題を再作成する
自由形式テキスト、プロキシによる追加、バージョン互換性は依然として不確実なままです。互換性が必要な場合は、安定した enum、バージョン、明示的なコンシューマーを使用してください。
可観測性なしでヘッダーを削除する
フィールドを削除しても、ステール配信や再検証の失敗は解決しません。外部ヘッダーを削除する前に、キャッシュ状態のメトリクス、トレーシング、アラートを確立してください。
103 Early Hints をキャッシュ警告として扱う
103 のタイミングと目的はリソースのヒントです。鮮度や再検証の失敗を表現することはできません。別々のフィールドと処理パスを維持してください。
削除可能であることをどのように証明するか？
クライアントの読み取り、プロキシ設定、エラー率、およびキャッシュメトリクスを観測します。期間を定めた二重書き込みウィンドウを実行し、単一层のカナリアリリースの後に拡大します。依存関係の証拠なしにグローバルに削除しないでください。