1. プロンプトとユースケース
あるコンテンツAPIが、管轄区域ごとに異なる結果を返しています。法務部門から、あるリソースが裁判所命令または法令に基づく削除要請の対象であることが確認され、ゲートウェイチームはステータスコードの規約を1つに統一したいと考えています。403、404、503と比較して451を使用すべきタイミングを説明し、レスポンスボディ、地域判定、キャッシュ、監査の振る舞いを設計してください。なお、サービスは不要なユーザー、訴訟、または規制当局の詳細情報を開示してはならないものとします。
2. 面接官がテストしていること
- 451があらゆる地域制限ではなく、法的または公共政策上の障害を伝えるものであることを理解しているか。
- 認可の失敗、リソースの欠落、一時的な障害、法的な利用不可を区別できるか。
- 透明性リンク、最小限の開示、監査証跡、キャッシュバリアントを1つの規約に統合できるか。
- コントローラーに条件分岐を1つ追加するだけでなく、プロキシ、CDN、マルチリージョン展開、変化する法的状態を考慮できるか。
3. 最初に確認すべき明確化のための質問
- このブロックは、裁判所の命令、法令に基づく通知、または製品独自の地域ポリシーのどれに基づいていますか？
- 対象はリソース、ユーザー、管轄区域、時間枠のどれですか？
- レスポンスに公開用の理由リンク、命令識別子、または異議申し立てルートを含めてもよいですか？
- レスポンスはCDNによってキャッシュされますか？また、地域とポリシーバージョンはキャッシュキーに含まれますか？
4. 30秒回答フレームワーク
サーバーがリソースを提供できない主な理由が法的または公共政策上の障害である場合にのみ451を返します。通常の認可には403、存在しないリソースまたは意図的に非公開のリソースには404、一時的なキャパシティ不足や依存関係の障害には503を使用します。レスポンスには、機械可読なブロックタイプと承認済みの透明性リンクを含めることができます。blocked-byリンク関係は説明ページを指すことができます。管轄区域とポリシーバージョンごとにキャッシュを分離し、ソースと有効期限を監査し、失効または取り消された法的状態によってサービスが復旧できるようにします。
5. ステップバイステップの詳細回答
ステップ 1: ステータスコードの境界を確立する
ポリシーの前に、識別情報、リソースの存在、サービスの正常性を確認します。権限のない認証済みユーザーには403が返され、存在しないターゲットや開示できないターゲットには404が返される場合があり、一時的な依存関係の障害や過負荷には503が使用され、Retry-Afterが含まれる場合があります。451は、法律または公共政策によってサーバーがそのリソースを提供できない場合にのみ有効です。「この地域では製品が提供されていない」という理由は、自動的に法的障害になるわけではありません。
ステップ 2: 法的ブロック判定をモデル化する
リソースまたはリソースファミリ、管轄区域、法的根拠タイプ、ソース参照、開始および終了時間、審査状態、異議申し立てルートを含む、バージョン管理されたポリシーレコードを保存します。リクエストコンテキストには信頼できる地域シグナルが必要ですが、IP位置情報、アカウントの住所、エグレスプロキシで不一致が生じる可能性があるため、優先順位と安全な不明時ポリシーを定義します。ポリシーエンジンにallowed、blocked_legal、またはblocked_productを返させ、製品ルールが法的理由に偽装されないよう、コントローラーがそれらの結果を451または403にマッピングします。
ステップ 3: レスポンスと透明性を設計する
type、policy_id、blocked_untilなどの安定した機械可読フィールドを維持しますが、機密性の高い訴訟資料、個人データ、未承認の当局名をボディに含めてはなりません。許可されている場合は公開説明ページを提供し、それを参照するためにLink: https://example.test/legal/block-123; rel="blocked-by"を使用します。法律で守秘が義務付けられている場合は、理由を創作するのではなく省略します。クライアントは451を通常の再試行では解決できないポリシー結果として処理する必要があります。
ステップ 4: キャッシュとマルチリージョン展開を処理する
CDNは451をキャッシュできますが、レスポンスは管轄区域、リソース、ポリシーバージョンによって変化しなければなりません。ある地域でのブロックが他の地域のキャッシュを汚染してはなりません。ポリシーの変更には短いTTLまたはアクティブな無効化を使用し、取り消し後にエッジノードを検証します。地域ごとに異なるサービスが実行されている場合は、エッジとオリジンで同じリクエストに対して不一致が発生しないよう、ポリシーバージョンと監査イベントを関連付けます。
ステップ 5: 安全に監査、取り消し、縮退運転を行う
機密性の高いユーザーデータを隠蔽しながら、リソース、地域シグナルソース、ポリシーバージョン、判定時刻、サービスバージョン、レスポンスコードをログに記録します。法的状態が期限切れになった場合、命令が取り消された場合、または異議申し立てが成功した場合は、ブロックを永続化するのではなく、ポリシーを再審査または許可の状態に移行します。ポリシーサービスが利用できない場合は、承認されたフェイルオープンまたはフェイルクローズのルールに従い、独立した運用エラーを出力します。ポリシーサービスのタイムアウトを451に変換してはなりません。
6. 高品質な回答例
まず理由を切り分けます。403は認可、404は存在しないか意図的に開示しない場合、503は一時的なサービス障害です。法律または公共政策によりサーバーがリソースを提供できない場合にのみ451を返します。ポリシーレコードにはリソース、管轄区域、法的根拠、開始・終了時刻、審査、異議申し立てのデータが含まれ、ポリシーエンジンは法的ブロックと製品の地域ルールを区別します。451レスポンスは承認された機械可読フィールドと透明性リンクのみを開示します。CDNキーには管轄区域とポリシーバージョンが含まれ、取り消し時にはキャッシュ無効化がトリガーされます。すべての判定は監査可能であり、ポリシーサービスの障害時は451と誤認させることなく事前定義されたセーフモードに従います。
7. よくある間違い
- すべての地域制限に対して451を返す → 製品ルールを法的根拠と誤認させる → 製品制限は個別にモデル化し、一貫した403またはビジネス規約を使用する。
- 403の代わりに451を使用する → 解決に結びつかない法的状態の変更をクライアントが待ち続ける可能性がある → まずブロックの真の原因を特定する。
- レスポンスで完全な訴訟ファイルを開示する → 機密情報が漏洩し、命令に違反する恐れがある → 承認されたフィールドと公開説明リンクのみを返す。
- キャッシュバリアントを無視する → 特定地域の451が他の地域を汚染する → 管轄区域とポリシーバージョンでキーを設定し、取り消しをテストする。
- ポリシーサービスがタイムアウトしたときに451を返す → 内部障害を法的決定に変えてしまう → 明示的なフェイルオープン/フェイルクローズの動作と個別の障害シグナルを使用する。
8. フォローアップの質問と回答
フォローアップ 1: クライアントは他の4xxレスポンスと同様に451を再試行すべきですか？
通常の再試行は効果がありません。クライアントは機械可読フィールドまたは説明リンクを読み取り、承認された次のステップをユーザーに提示するか、異議申し立てを開始するか、合法的なリソースを選択する必要があります。ポリシーバージョンの変更または認可コンテキストの変更後にのみ再試行してください。
フォローアップ 2: 国固有の命令がキャッシュを汚染するのを防ぐにはどうすればよいですか？
キャッシュキーまたはバリエーション（Vary）に、リソース、信頼できる管轄区域シグナル、ポリシーバージョンを含めます。ポリシーが取り消された場合はアクティブに無効化し、複数の地域からのレスポンスをサンプリングして確認します。
フォローアップ 3: 404を使用して法的ブロックを隠すことはできますか？
法律やセキュリティポリシーで許可されている場合は最小限の開示が有効な場合もありますが、透明性と診断性は低下します。規約で451を選択する場合は、承認された情報のみを開示してください。重要な特性は一貫性、監査可能性、および法的な承認です。