RFC 6585 Quiz

**Explanation:** RFC 6585 を, 「番号が増えた」という話で終わらせるのはもったいないです. 本質は client と server のやり取りを少し具体的にすることです. **status code** は server から client への意味づけです. **具体的な status code** があると, retry, backoff, 修正方法を client が読み取りやすくなります. API gateway, SDK, browser, proxy の設計で, 400 や 503 だけでは行動が曖昧になる場面を減らせます. 良い設計レビューでは, 「この failure を client がどう解釈して次に何をするか」まで確認します. A: 既存体系を捨てる RFC ではありません. B: これが RFC 6585 の価値です. C: 新しい auth scheme を定義する文書ではありません.

**Explanation:** 428 は conflict 系の error と混ざりやすいですが, RFC 6585 では lost update を避けるために conditional request を強制する用途が中心です. **precondition** は `If-Match` のように, 条件が満たされたときだけ method を適用する仕組みです. **lost update** は古い内容を持った client が新しい更新を消してしまう事故です. document 編集, 設定管理, admin API など, 同じ resource を複数人や複数 process が触る場面で重要です. 428 の価値は error を返すこと自体ではなく, 「条件を付けてもう一度送ってほしい」と client に伝えられることです. A: conditional updateを必須にするとclientが変更対象のversionを示すため, stale writeによる新しい内容の上書きを防げます. B: quota超過には`429 Too Many Requests`を使い, 必要なら`Retry-After`などで待機時間を伝えます. C: network loginの介入には`511 Network Authentication Required`を使います. lost updateの条件ではありません.

**Explanation:** RFC 6585 Section 3は`428 Precondition Required`のrecovery pathも扱い, responseが成功する再送方法を説明することをSHOULDとします. blind retryをさせるためのerrorではありません. **validator** は `ETag` のように version を識別する手掛かりです. `If-Match` は, その validator が一致するときだけ更新したい, と伝える条件付き header です. collaborative editing や admin 画面で, 上書き事故を防ぎながら再送する設計に直結します. server 側は 428 を返すだけでなく, どの conditional request を期待するかを説明できると親切です. A: 条件なし再送では lost update の危険が残ります. B: これが 428 の意図に沿った retry です. C: 503 に読み替える話ではありません.

**Explanation:** per-client の rate limiting と, service 全体の availability 低下を混同すると, client の retry も運用判断もずれます. **429 Too Many Requests** は client 側の rate や quota の超過を表します. **503 Service Unavailable** は service 側の広い availability 問題を示します. **511** は local network access の話です. SDK の backoff, rate-limit dashboard, on-call の切り分けで, 「誰の問題か」を正しく伝える必要があります. status code は責任分担を伝える道具でもあります. A: service が元気で client だけが制限超過なら 429 が自然です. B: 503 は service 側の availability 問題を連想させます. C: 511 は captive portal 系の用途です.

**Explanation:** `Retry-After` は小さな header ですが, client の行動を大きく変えます. ここを雑にすると retry storm が起きやすいです. **Retry-After** は, どれくらい待ってから再試行すべきかを示す response header です. 値は **delay-seconds** でも **HTTP date** でも表せます. SDK, browser, bot, batch job の backoff 実装を揃えるときに重要です. 「あとで試して」と伝えるなら, どのくらい待つかも一緒に伝える方が client 実装は安定します. A: これが最も典型的な使い方です. B: HTTP date も使えます. C: 失敗の意味に retry の手掛かりを足せます. D: 有用ですが, 常に必須とは限りません.

**Explanation:** 431 を 1 行の bad header 用だと思い込むと, cookie 肥大化や proxy chain の事故を見落とします. **header field** は個別の header です. **request header 全体** は message に付く header 群全体です. cookie の肥大化, oversized auth token, `Forwarded` や `X-Forwarded-*` の伸びすぎ, proxy 制限などで頻出です. 431 は app の bug だけでなく, middleware や proxy の積み重ねで起きることも多いです. A: 全体が大きすぎる場合にも使えます. B: 文法 error だけの話ではなく, サイズ問題です. C: 特定できるなら原因 field を伝えると debug しやすくなります. D: body size の問題とは別です.

**Explanation:** RFC 6585 Section 4は429 responseをcacheへ保存してはならないと定めます. **shared cache** は複数 client のあいだで response を再利用します. **request 固有の条件** には precondition, quota 状態, header size, captive portal 状態などがあります. CDN, reverse proxy, API gateway で, tenant をまたいだ誤配信や謎の 429 を防ぐのに重要です. status code は UI 向けメッセージだけではなく, intermediary の挙動も制御します. A: 他の client にまで 429 を広げるのは危険です. B: RFC 6585 はこれらを cache してはいけないとしています. C: 200 に潰すと protocol semantics が壊れます.

**Explanation:** RFC 6585 Section 7は,attack中のserverにこれらのstatus codeを返す義務はなく,connection dropなど別のactionも選べるとします.このallowanceはconnection dropを許しますが,常に要求するものではありません. **request flood** や **header-bomb attack** は server 資源を食い潰す攻撃です. **防御** には connection drop のような, 応答コストを抑える手段も含まれます. DDoS, bot 対策, edge proxy の incident で, 正確さより survivability を優先する判断が必要になります. semantics は大事ですが, response 自体が attack cost になるなら先に守るべきです. A: attack 中に毎回丁寧な response を返す必要はありません. B: 503 一択でもありません. C: これが RFC の security note に近い考え方です.

**Explanation:** 511 は「auth が必要」という文字面で誤用されやすいです. でも普通の origin login failure には向きません. **intercepting proxy** や **captive portal** は network path 上で access を止める存在です. **origin API** は本来の application server です. hotel Wi-Fi, guest network, enterprise onboarding, OS の captive portal 検出で重要です. 511 を app login に流用すると, layer の意味が崩れて client 側の理解もずれます. A: app の session 切れは 511 の主戦場ではありません. B: これが RFC 6585 の想定に近いです. C: cache の鮮度問題ではありません.

**Explanation:** RFC 6585 Section 5によると, `431 Request Header Fields Too Large`はrequest header fieldが大きすぎるためserverが処理しないことを示します. field sizeを減らせば再送でき, 1つのfieldが原因ならresponseはそのfieldを示すべきです. 431 responseはcacheへ保存してはならないため, 修正後のrequestはそのerror responseではなく改めて評価されます. A: responseが特定した条件を修正してからretryしています. B: `If-Match`はpreconditionとlost updateへ対処しますが, 大きすぎるheader fieldは小さくしません. C: 待機はrate limitingには役立ちますが, 変更しないCookie fieldは時間が経っても小さくなりません.

**解説:** A: unauthenticated TLS stream内のstatus codeは, それを送ったintermediaryを認証できません. B: RFC 6585 Section 7.4はTLSへのcaptive-portal interceptionがcertificate errorを起こすと述べます. RFC 6585はHTTPが利用できた後の511 semanticsを定義しますが, TLS peer authenticationのbypassを許可しません. C: 有効な511 representationが別のlink targetを示すことはありますが, failed TLS connectionを遡って認証できません. D: credentialを省けば一部のexposureは減りますが, `api.example`に対するpresented certificateのvalidityは変わりません.