質問と想定されるシナリオ
あなたは、悪意のある添付ファイルのフィルタリング、プライベートフィールドの削除、またはレスポンスのトランスコードを行う API ゲートウェイを担当しています。オリジンリクエストは成功しますが、ダウンストリームの表現はもはやオリジンのバイト列ではありません。203 を返すべきタイミング、バリデータの処理方法、およびクライアントが変換されたデータを信頼できるオリジンデータとして扱わないようにする方法を説明してください。
HTTP 203 は、変換プロキシがオリジンの 200 レスポンスからヘッダーまたはコンテンツを変更したことを示す成功レスポンスです。これは一般的なエラーや認可ステータスではなく、「成功したが、変換された」ことを示すプロトコルシグナルです。
面接官がテストしているポイント
- 203、200、304、4xx、および 5xx の正確な境界。
- 変換がキャッシュ、ETag、署名、および後続のリクエストに与える影響の理解。
- オリジン表現とダウンストリーム表現の間の追跡可能な監査リンク。
- 複数のプロキシ、オリジン障害、および 203 を解釈できないクライアントの処理。
- プロトコルセマンティクスをテスト可能なヘッダーとキャッシュ動作に変換する能力。
回答前の明確化事項
- 変更内容はマルウェアのフィルタリング、トランスコード、それともユーザー固有のマスキングですか？これはキャッシュ共有に影響します。
- クライアントは 203 を認識できますか？認識できない場合、互換性レイヤーが必要ですか？
- オリジナルの表現は追跡可能である必要がありますか？署名と監査レコードには両方のバージョンが必要です。
- 変換は決定論的ですか？ルールが異なる場合、ルールバージョンはキャッシュキーに含まれます。
30秒の回答フレームワーク
まず、ゲートウェイがアプリケーションコンテンツまたは関連ヘッダーを変更したかどうかを確認します。表現が変更されたオリジンの成功レスポンスには 203 を設定し、変更されていない表現は 200 のままにします。203 は、クライアントの既存の表現を検証するだけの 304 を置き換えるものではありません。ダウンストリーム表現用の ETag を生成し、コンテンツネゴシエーション、ルールバージョン、テナント境界をキャッシュキーに含めます。監査レコードはオリジンバージョンを変換後の出力にリンクします。オリジン障害は実際の障害セマンティクスを維持します。
ステップバイステップの詳細な回答
1. ステータスコードの境界を確立する
200 は、アプリケーション変換を宣言することなく現在のレスポンスが成功したことを示します。203 は、リクエストは成功したが、変換プロキシがオリジンの 200 からヘッダーまたはコンテンツを変更したことを示します。304 は新しい表現を保持せず、クライアントに検証済みの表現を再利用するよう求めます。フィルタリングの失敗、拒否、およびオリジンタイムアウトには、適切な 4xx または 5xx セマンティクスを使用します。
2. 変換を分類する
マルウェアによってブロックされた URL の置換、プライバシーフィルタリング、フォーマットのトランスコード、ミラーメタデータなどは 203 を正当化できます。転送圧縮やホップバイホップフィールドのみの変更は、通常、アプリケーション表現を変更しません。ゲートウェイは何がなぜ変更されたかを記録する必要があります。
3. バリデータを再計算する
オリジンの ETag はオリジンの表現を記述します。変換された出力には、その出力に対して有効なダウンストリーム ETag が必要です。ルールバージョンによってバイトが変更される場合は、それをキャッシュキーまたはバリデータ入力に含めます。そうしないと、ルールのロールアウトによって古い出力が再利用される可能性があります。
4. キャッシュとネゴシエーションを設計する
Vary、コンテンツエンコーディング、言語、テナント、および変換ルールはすべて共有可能性に影響します。プライバシーに敏感な結果はデフォルトでプライベートキャッシュとし、決定論的なパブリック変換のみを共有します。If-None-Match の場合、クライアントが持っていないバイトに対してオリジンの 304 を転送するのではなく、ゲートウェイの表現を検証します。
5. 署名と監査証跡を保護する
元のバイトに対するオリジンの署名は、変更されたダウンストリームボディを証明できません。変換された表現に再署名するか、無効な署名を削除します。オリジンリクエスト ID、オリジン ETag、ルールバージョン、出力 ETag、および変換理由を記録します。
6. 複数プロキシを処理する
各レイヤーは変換の来歴を保持し、非べき等なルールの繰り返しを避ける必要があります。クライアントが 203 を解釈できない場合、明示的な互換性レイヤーが文書化されたメタデータとともに 200 を返すことができますが、セキュリティやプライバシーの変換を暗黙的に隠蔽してはなりません。
7. 検証とロールバック
オリジン 200、変換された 203、変更のない 200、ダウンストリーム 304、ルールロールアウト、オリジンタイムアウト、およびフィルター失敗をテストします。ロールバック中は、古い ETag と新しい ETag が衝突しないことを確認し、古いルールの下で作成された共有キャッシュエントリを検査します。
質の高い模範回答
私は 203 を「リクエストは成功したが、変換プロキシがオリジンの表現を変更した」という宣言として扱います。変更されていないアプリケーションレスポンスは 200 のままです。変換されたものは 203 です。304 はダウンストリーム表現を検証するだけであり、オリジンからそのまま透過的に渡すことはできません。ゲートウェイは変換されたバイト列に対して新しい ETag を作成し、ルールバージョン、ネゴシエーション、プライバシー境界によってキャッシュキーを設定します。オリジン署名が元のバイトを対象としていた場合、ゲートウェイは再署名するか削除します。テストは 200/203/304、ルール変更、プロキシチェーン、オリジン障害をカバーし、クライアントがフィルタリングされたデータをオリジンデータと誤認しないようにします。
よくある間違い
- すべてのプロキシレスポンスに対して 203 を返す → セマンティクスがノイズになる → 実際の表現変更に対してのみ使用する。
- オリジン ETag を再利用する → バリデータが誤ったバイトを記述する → ダウンストリーム出力用に ETag を生成する。
- 203 をエラーとして扱う → クライアントが再試行またはアラートを出す可能性がある → 実際の 4xx/5xx 障害セマンティクスを維持する。
- オリジン 304 をそのまま転送する → 変換後のキャッシュが無効になる可能性がある → ダウンストリーム表現を検証する。
- ルールバージョンを無視する → ロールアウト時に古い出力が配信される可能性がある → バージョンをキーまたはバリデータに含める。
フォローアップの質問と回答
Content-Encoding のみの変更に 203 は必要ですか？
通常は不要です。転送エンコーディングはトランスポート処理です。アプリケーション表現が変更されていない場合は、200 を維持し通常のネゴシエーションルールを適用します。
203 レスポンスをキャッシュで共有できますか？
はい。変換が決定論的であり、変動するすべての次元がキー設定され、ユーザー固有のプライベートデータが存在しない場合は共有可能です。テナント固有の出力はプライベートにする必要があります。
オリジンの 203 がゲートウェイによってさらに変換された場合はどうなりますか？
両方の来歴リンクを保持し、最終的な ETag を計算して、べき等性を検証します。べき等性が保証されない場合は、1 回の変換のみを許可します。
互換性レイヤーで 203 を 200 に変換できますか？
検出可能なメタデータと監査ロギングを伴い、明示的に文書化されている場合は可能です。セキュリティフィルタリングやプライバシーのマスキングを暗黙的に隠蔽してはなりません。
オリジンが 304 を返したが、ローカルに変換済みオブジェクトが存在しない場合はどうなりますか？
304 を直接返してはいけません。使用可能な表現を取得して変換するか、ローカル表現の欠如を反映した障害を返します。