プロンプトとコンテキスト
このネットワークおよび API の基礎に関する設問は、バックエンド、プラットフォーム、インフラストラクチャの職種に適しています。リソースは法的要件によって拒否されており、ブロックはオリジン、CDN、ISP、または検索エンジンで発生する可能性があります。目標は、451 がどのような場合に適切であるか、透明性をどのように提供するか、そして法的ブロックが通常の権限エラーや再試行可能な障害とは異なる理由を説明することです。
面接官が評価しているポイント
- セマンティクスと責任範囲によって 451、403、404、5xx を区別できるか？
- 451 がリソースの存在を証明することなく法的要求を示すことを知っているか？
- レスポンスボディ、
Link: rel="blocked-by"、キャッシュ、プロキシの動作を正しく組み合わせられるか？ - プライバシー、誤解を招く開示、クライアントの使いやすさ、監査ログ、マルチリージョンでの検証を考慮しているか？
確認すべき明確化のための質問
実際に誰がブロックを強制しているのか、結果が地域によって異なるか、法的根拠を開示できるか、手前に共有キャッシュが存在するか、クライアントがブラウザ、モバイルアプリ、API コンシューマーのいずれであるかを確認します。ユーザーに単に権限がない場合は 401 または 403 を使用します。リソースが存在しない場合は、実装の詳細を隠すためだけに 451 に変更しないでください。開示が禁止されている場合は、公開する情報と内部の証跡を分けて定義します。
30秒の回答フレームワーク
法的要求によってサービスがアクセスを拒否している場合にのみ 451 を使用し、監査可能なボディに法的根拠と適用範囲を記載します。CDN やその他の仲介者がブロックを強制している場合、rel="blocked-by" を持つ Link は、要求を出した当局ではなく、それを実行している主体を識別します。地域やポリシーの変動性に基づいてキャッシュの動作を選択し、クライアントに明確な利用不可ステータスを表示し、自動再試行や別のネットワークなら機能するという保証を避けます。最後に、オリジン、プロキシ、キャッシュ、地域の動作を併せて検証します。
ステップごとの詳細解説
- セマンティクスを分類する。 451 は法的要求によりサーバーがリソースを拒否していることを意味し、403 は特定されたリクエスターが許可されていないことを意味し、404 はリソースが存在しないか、その存在が意図的に隠されていることを意味します。451 はリソースが存在することを証明するものではなく、技術的な障害でもありません。
- 強制を実行する主体を特定する。 オリジン、CDN、ISP、DNS サービス、または検索エンジンが実際のブロック主体である可能性があります。その主体は
rel="blocked-by"を持つLinkヘッダーで自身を識別します。当局やポリシーの説明はその関係ではなく、ボディまたはポリシーページに記載します。 - レスポンスを設計する。 法的またはポリシーの根拠、発行元、影響を受ける地域やリソースクラス、異議申し立てやヘルプへの経路を説明します。開示がさらなるリスクを生む場合は、内部監査記録に完全な根拠と承認者を保持しつつ、必要な情報のみを公開します。
- キャッシュを処理する。 RFC 7725 では 451 のデフォルトでのキャッシュが許可されているため、頻繁に変更される法的または地域的な状態には、明示的な
Cache-Control、短い TTL、またはno-storeが必要です。共有キャッシュのキーには、ある地域の結果が別の地域に漏洩しないよう、ブロックに影響を与えるすべてのディメンションを含める必要があります。 - クライアントの動作を定義する。 ブラウザは明確なコンテンツ制限状態を表示します。API クライアントは 451 を再試行不可能なポリシーエラーとして扱い、ステータス、ブロックの詳細、リクエスト ID を保持します。500 に書き換えたり、プロキシや VPN 経由でポリシーを自動的に回避したりしてはなりません。
- 検証と監視を行う。 オリジン直接、CDN、複数リージョン、キャッシュウォームおよびキャッシュコールドのリクエスト、さまざまなクライアントからのステータス、ボディ、ヘッダー、キャッシュヒットを比較します。監査イベント、ルールバージョン、強制主体、取り消し時間を記録し、ポリシーが変更された場合は影響を受けるキャッシュをパージします。
優れた回答例
まず、拒否が法的に真正なものであることを確認します。権限の問題は 403 を返し、存在しないリソースは 404 を返します。451 はリソースが存在すると主張することなく、法的なブロックを伝えます。オリジンまたは CDN がそれを強制する場合があるため、Link で実際のブロック主体を特定します。
HTTP/1.1 451 Unavailable For Legal Reasons
Content-Type: application/problem+json
Cache-Control: private, max-age=300
Link: <https://blocker.example/policy/123>; rel="blocked-by"
{
"status": 451,
"title": "Unavailable For Legal Reasons",
"detail": "Access is restricted in this region under the cited policy.",
"policy_id": "policy-123",
"request_id": "req-7f2"
}ボディはユーザーに十分な説明と申し立て経路を提供し、内部監査では完全な法的根拠、地域の決定、ルールバージョン、操作者を保持します。451 はデフォルトでキャッシュ可能であるため、キャッシュキーには地域とルールバージョンを含め、ポリシー状態が迅速に変わる場合は短い TTL または保存不可を設定します。クライアントはポリシー制限を提示し、自動再試行を停止します。テストでは、オリジン、CDN、キャッシュヒット、地域の変更、ルールの取り消し、開示が制限されているケースをカバーします。
よくある間違い
- すべての拒否に対して 451 を返す → 権限、リソース不在、法的ブロックの区別がつかなくなる → 401、403、404、451、または 5xx を選択する前に理由を分類する。
blocked-byに法的機関を設定する → リレーションのセマンティクスが誤り → そこで強制主体を特定し、ポリシーはボディで個別に説明する。- デフォルトのキャッシュ可能性を無視する → ある地域の結果が別の地域と共有されてしまう → キャッシュキー、TTL、および必要な
no-storeの動作を設計する。 - 451 を自動再試行する → リクエストを繰り返してもポリシー状態は変更されない → 対処可能なヘルプテキストを伴う再試行不可能なポリシーエラーとして扱う。
- 451 をリソースが存在する証拠として扱う → サイト情報が漏洩する可能性がある → このステータスは存在を確定するものではないことを明記する。
フォローアップの質問と回答
法的要求によって正確な条項の開示が禁じられている場合はどうすればよいですか？
必要な制限とリクエスト ID のみを返し、詳細をでっち上げないようにします。法的根拠、承認者、バージョンは内部監査記録に保持します。クライアントには、ネットワーク障害ではなくポリシー制限であることを知らせる必要があります。
451 レスポンスはキャッシュできますか？
はい。RFC 7725 ではデフォルトでキャッシュ可能とされていますが、変動性と機密性によってポリシーが決まります。地域、ユーザーグループ、またはルールバージョンによって結果が変わる場合は、適切なキャッシュキーと短い TTL（場合によっては no-store）を使用し、ブロックが解除されたときにキャッシュをパージします。
CDN は 451 を返しているが、オリジンは 200 を返しています。ブロック主体はどちらですか？
実際にリクエストを拒否している主体は CDN であり、blocked-by に表示されるべきです。オリジンのログには、そのブロックを実行しなかったことが示されているはずです。レイヤーを混同しないように、オリジン直接、CDN、キャッシュの状態を個別に検証してください。