RFC 6585 Quiz

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

**Explanation:** **問題を出した背景:** 428 は conflict 系の error と混ざりやすいですが, RFC 6585 では lost update を避けるために conditional request を強制する用途が中心です. **用語:** **precondition** は `If-Match` のように, 条件が満たされたときだけ method を適用する仕組みです. **lost update** は古い内容を持った client が新しい更新を消してしまう事故です. **実務での機会:** document 編集, 設定管理, admin API など, 同じ resource を複数人や複数 process が触る場面で重要です. **選択肢:** - A (correct): これが 428 の代表的な使いどころです. - B (incorrect): quota 超過なら `429 Too Many Requests` が近いです. - C (incorrect): network login の話は `511 Network Authentication Required` です. **関連:** 428 の価値は error を返すこと自体ではなく, 「条件を付けてもう一度送ってほしい」と client に伝えられることです.

**Explanation:** **問題を出した背景:** 428 の価値は recovery path にあります. blind retry をさせるための error ではありません. **用語:** **validator** は `ETag` のように version を識別する手掛かりです. `If-Match` は, その validator が一致するときだけ更新したい, と伝える条件付き header です. **実務での機会:** collaborative editing や admin 画面で, 上書き事故を防ぎながら再送する設計に直結します. **選択肢:** - A (incorrect): 条件なし再送では lost update の危険が残ります. - B (correct): これが 428 の意図に沿った retry です. - C (incorrect): 503 に読み替える話ではありません. **関連:** server 側は 428 を返すだけでなく, どの conditional request を期待するかを説明できると親切です.

**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 の切り分けで, 「誰の問題か」を正しく伝える必要があります. **選択肢:** - A (correct): service が元気で client だけが制限超過なら 429 が自然です. - B (incorrect): 503 は service 側の availability 問題を連想させます. - C (incorrect): 511 は captive portal 系の用途です. **関連:** status code は責任分担を伝える道具でもあります.

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

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

**Explanation:** **問題を出した背景:** RFC 6585 の重要な点のひとつが cache です. これらの response を共有事実のように再利用すると, かなり危険です. **用語:** **shared cache** は複数 client のあいだで response を再利用します. **request 固有の条件** には precondition, quota 状態, header size, captive portal 状態などがあります. **実務での機会:** CDN, reverse proxy, API gateway で, tenant をまたいだ誤配信や謎の 429 を防ぐのに重要です. **選択肢:** - A (incorrect): 他の client にまで 429 を広げるのは危険です. - B (correct): RFC 6585 はこれらを cache してはいけないとしています. - C (incorrect): 200 に潰すと protocol semantics が壊れます. **関連:** status code は UI 向けメッセージだけではなく, intermediary の挙動も制御します.

**Explanation:** **問題を出した背景:** 正確な status code を返すことと, attack 中に生き残ることは別問題です. RFC 6585 もその現実を認めています. **用語:** **request flood** や **header-bomb attack** は server 資源を食い潰す攻撃です. **防御** には connection drop のような, 応答コストを抑える手段も含まれます. **実務での機会:** DDoS, bot 対策, edge proxy の incident で, 正確さより survivability を優先する判断が必要になります. **選択肢:** - A (incorrect): attack 中に毎回丁寧な response を返す必要はありません. - B (incorrect): 503 一択でもありません. - C (correct): これが RFC の security note に近い考え方です. **関連:** semantics は大事ですが, response 自体が attack cost になるなら先に守るべきです.

**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 検出で重要です. **選択肢:** - A (incorrect): app の session 切れは 511 の主戦場ではありません. - B (correct): これが RFC 6585 の想定に近いです. - C (incorrect): cache の鮮度問題ではありません. **関連:** 511 を app login に流用すると, layer の意味が崩れて client 側の理解もずれます.

**Explanation:** **問題を出した背景:** RFC 6585 の価値は 4 つの番号を覚えることではなく, failure の層と client 行動を揃えることです. **用語:** **quota 超過**, **service outage**, **conditional write**, **cache**, **network mediation** は, RFC 6585 を使いこなすときの主要論点です. **実務での機会:** API 契約, SDK retry, CDN 設定, captive portal 対応をまたいで, 仕様と運用のズレを減らせます. **選択肢:** - A (correct): RFC 6585 の設計意図を operational に捉えています. - B (incorrect): 新しい code が増えても, generic handling は依然として必要です. - C (incorrect): 511 はもっと限定的な用途です. **関連:** RFC 6585 を使える知識にするには, 各 code が retry, cache, auth, ownership にどう効くかまで話せる必要があります.