RFC 9111 Quiz

**Explanation:** cache は速くする道具として語られがちですが, 実際には「保存してよいか」の判断が先に来る場面が多いです. **no-store** は conforming な private cache と shared cache に response を保存しないよう指示します. **private** は shared cache での保存を禁止しますが, browser などの private cache での保存は許します. 口座情報, 管理画面, 医療情報, 社内ポータルのレビューで, 「shared cache だけ防げば十分か」が論点になります. - A (incorrect): **public** は shared cache での再利用を許すので, 個人データには不適切です. - B (incorrect): **private** は shared cache での保存を禁止しますが, browser の private cache には保存できるため, この要件を満たしません. - C (correct): **no-store** は conforming な private cache と shared cache に response を保存しないよう指示するため, この要件に合います. cache 設計は性能だけでなく data handling の判断でもあります. RFC 9111 は, malicious または compromised な cache や network eavesdropping に対し, **no-store** だけでは信頼できる十分な privacy mechanism にならないと注意しています.

**Explanation:** **no-cache** と **no-store** の取り違えは, 現場で一番起きやすい cache 設計ミスのひとつです. **no-cache** は「cache するな」ではなく, 「再利用するなら origin に確認しろ」という意味です. その確認には **ETag** や **Last-Modified** が使われます. 管理画面やダッシュボードで, 帯域は節約したいが stale のまま出したくない, という場面でよく出ます. - A (incorrect): **no-store** は response の保存を禁止しますが, **no-cache** は保存自体を禁止する directive ではありません. - B (correct): cache は response を保存できますが, 再利用前に request を origin へ転送して validation を行い, validation に成功した response を受ける必要があります. - C (incorrect): 引数なしの **no-cache** は private cache と shared cache の両方の再利用を制約し, private cache 専用にはしません. cache を完全停止するより, conditional request に寄せた方が良いケースは多いです.

**Explanation:** browser と CDN を同じ寿命で扱ってしまい, どちらか一方の都合に引っ張られる設計はよくあります. **max-age** は一般的な freshness 指示です. **s-maxage** は **shared cache** 向けの寿命を別に切るためのものです. storefront, catalog API, public landing data では, edge で負荷を吸いたい一方, browser ではもう少し細かく更新を見たいことがあります. - A (incorrect): browser と shared cache の双方で, response が 10 分間 fresh と扱われます. - B (correct): browser には **max-age=60** が適用され, shared cache では **s-maxage=600** がその値を上書きします. - C (incorrect): **private** を付けると CDN での再利用ができません. cache policy は 1 つの TTL を雑に置くのではなく, 利用層ごとに分けて考えると設計が安定します.

**Explanation:** 古い middleware や framework が **Expires** を足してくるせいで, 実際の優先順位を曖昧に理解したまま運用されがちです. **Cache-Control** は現代的な cache 制御の中心です. **Expires** は絶対時刻ベースの古い仕組みです. CDN や backend framework の default header を見直すときに, どの指示が効いているかを判断する必要があります. - A (correct): freshness lifetime の計算では **max-age** が **Expires** より先に評価されます. - B (incorrect): response に **Cache-Control: max-age** があれば, recipient は **Expires** を無視しなければなりません. - C (incorrect): freshness は定められた優先順位で決まり, 長い寿命になる値を cache が選ぶ仕組みではありません. 明示的な相対寿命を置ける **Cache-Control** を中心に設計する方が事故が少ないです.

**Explanation:** cache 周りでは, freshness, variant 選択, validation を一緒くたにしてしまうことが多いです. **validator** は「手元の表現がまだ同じか」を確かめるための手掛かりです. 代表例は **ETag** と **Last-Modified** です. 304 が多い, origin に無駄に取りに行く, 逆に stale を出す, といった障害の切り分けで重要です. - A (correct): **ETag** は conditional request で representation を照合する validator です. - B (incorrect): **Age** は origin での生成または正常な validation からの経過時間を見積もる field で, validator ではありません. - C (correct): **Last-Modified** は modification date に基づく conditional validation に使えます. - D (incorrect): **Vary** は stored response の選択時に照合する request field を指定し, origin の現在状態との比較には使いません. 「どの entry を選ぶか」と「その entry を今も使えるか」は別の判断です.

**Explanation:** 304はbodyを返すsuccess responseではなく, stored responseの再利用可否を判断するvalidation resultです. **304 Not Modified** は validation の結果です. 既に持っている representation body をそのまま使ってよい, という意味です. browser devtools の見方, reverse proxy の実装, origin の条件付き GET 最適化で頻繁に出ます. - A (incorrect): 304 は validation metadata を提供する response であり, 空の replacement representation ではありません. cache は選択済みの stored body を維持します. - B (correct): cache は既存の representation body を再利用し, validation response の metadata で更新対象の stored header field を更新します. - C (incorrect): cache は, 304 から受けた applicable な field を使って, 対象となる stored response の header field を更新する必要があります. conditional request の価値は, 正しさを保ったまま転送コストを減らせる点にあります.

**Explanation:** 多言語配信の事故は freshness の問題ではなく, そもそも別 variant を同じ entry と見なしていることが原因な場合が多いです. **Vary** は, request header の何が representation 選択に効くかを cache に伝えます. **Accept-Language** はその典型です. 多言語サイト, device 別配信, 圧縮形式違いの配信で, 「別の人向けの内容が出る」事故を防ぎます. - A (correct): **Vary: Accept-Language** は, language negotiation に使った request field を stored-response matching に含めます. - B (incorrect): **Age** は variant の識別には使いません. - C (incorrect): **Last-Modified** は freshness 確認寄りで, variant 分離そのものはしません. **Vary** は「どれを選ぶか」の話で, validator は「選んだものが今も使えるか」の話です.

**Explanation:** 「認証付きだから全部 no-cache」と「重いから CDN で全部 cache」の両極端がよく起きます. **shared cache** は複数 client で再利用される cache です. RFC 9111 は Authorization 付き request に対し, **must-revalidate**, **public**, **s-maxage** を shared caching を許す response directive として挙げています. token 付き API の CDN 利用, service mesh の cache, edge 認証後の public data 配信で出てきます. - A (correct): **public** は response を明示的に cacheable とし, 認証付き request に対する response の shared caching を許します. - B (incorrect): **private** は shared cache の保存を禁止し, 認証付き response の例外を与えません. - C (correct): **s-maxage** は shared-cache maximum age を定め, stale 後の origin validation を条件に shared caching を許します. - D (correct): **must-revalidate** は shared caching を許す一方, stale 後は origin validation 成功まで再利用を禁止します. - E (incorrect): **no-store** は private cache と shared cache の双方に保存を禁止します. 認証の有無より, 実際に user ごとに違う内容なのか, 共有して安全なのかを headers で明示することが大切です.

**Explanation:** **private** を「機密情報なので保存禁止」と読み違えるケースが多いです. 引数なしの **private** response directive は, shared cache が response を保存してはならないことを示します. private cache は通常の cache 条件に従って保存できます. user 向け dashboard, personalized top page, BFF endpoint の policy を決めるときによく使います. - A (incorrect): **ETag** は後の validation に使えますが, **private** の保存制限は validator の有無に依存しません. - B (correct): 引数なしの **private** は shared cache の保存を禁止し, 通常の制約に従う private cache の保存は許します. - C (incorrect): 毎回の再利用前に validation を要求するのは引数なしの **no-cache** であり, **private** は保存範囲を制御します. conforming な private cache での保存も許容できないなら, **no-store** がより強い指示です. どちらの directive も message confidentiality は保証しません.

**Explanation:** shared cache に向くものを, content-type や実装言語ではなく, 再利用可能性で見分けられる必要があります. **public** は shared cache での保存を許す指示です. user 非依存で, 内容が安定している資産に向きます. CDN で負荷を吸う対象を選ぶとき, image, script, doc, catalog のどれを edge に乗せるかで判断します. - A (correct): 全 user に同じ version 付き static asset は, shared cache で安全に再利用しやすい候補です. - B (incorrect): user 固有の profile page を shared cache で再利用すると, 別 user の内容を返す危険があります. - C (incorrect): security-sensitive な one-time result を shared cache に保存・再利用させる policy は適切ではありません. 「誰に返しても同じか」と「しばらく stale でも許せるか」をまず確認すると判断しやすいです.

**Explanation:** stale の許容度は endpoint ごとに違います. 在庫, quota, 権限のようなデータは stale の一発が大きいです. **must-revalidate** は, stale になった後の再利用を validation 成功に縛る指示です. inventory, entitlement, seat availability, 金融枠のように, stale をそのまま出すと誤処理に直結する場面で重要です. - A (incorrect): **no-store** は保存を禁止するため, 設問が意図する fresh な間の再利用まで失わせます. - B (incorrect): **public** は cacheability を変えますが, stale 後に origin validation を必須にする directive ではありません. - C (correct): **must-revalidate** は保存や fresh な間の再利用を禁止しませんが, stale 後は origin validation が成功するまで再利用を禁止します. freshness を決める指示と, stale 後の扱いを決める指示は分けて考えると整理しやすいです.

**Explanation:** freshness header が無いと「じゃあ cache されない」と思い込むと, 実際の platform 挙動を読み違えます. **heuristic caching** は, 明示的な寿命指定がないときに, cache が一定のルールで freshness を推定する考え方です. 古い service の前に CDN を置くときや, default 動作で意図せず cache されるかをレビューするときに出ます. - A (incorrect): stale になったこと自体は新しい heuristic lifetime の根拠になりません. 元の freshness lifetime が明示的に定められている場合もあります. - B (correct): 明示的 expiration がなく, response が heuristically cacheable なら, cache は heuristic freshness lifetime を割り当てられます. - C (incorrect): validator は revalidation に使いますが heuristic freshness の開始条件ではなく, 明示的 lifetime があればそちらを使います. heuristic は便利ですが, 大事な endpoint では推測任せにせず explicit に書く方が安全です.

**Explanation:** request 側の cache directive は知名度が低く, 読み飛ばされがちです. **min-fresh** は client 側の希望で, 受け取る response が今すぐ stale になるようなものを避けたい, という意味です. prefetch, offline-aware client, 次の操作まで短時間だが fresh さを保ちたい workflow で役立ちます. - A (correct): **min-fresh=N** は, freshness lifetime が current age より少なくとも N 秒長い response を望むことを表します. - B (incorrect): 許容する staleness は **max-stale** で表し, **min-fresh** ではありません. - C (incorrect): **min-fresh** は希望する残り freshness を示すもので, validation の開始を遅らせたり禁止したりはしません. cache は origin の一方的命令だけでなく, client の許容度も含めて読むと理解が深まります.

**Explanation:** client 側の許容度を知らないまま cache を語ると, 可用性重視と整合性重視の違いを説明できません. **max-stale** は stale を一定範囲で受け入れてよい, という request 側の意思表示です. degraded mode, offline 寄りの UX, stale でもまず返したい検索や一覧で考え方が出てきます. - A (incorrect): response age の上限は request の **max-age** が制約し, stale の許容を表すものではありません. - B (correct): 値付きの **max-stale** は freshness 超過の許容秒数を定め, 値なしなら任意の age の stale response を許容します. - C (incorrect): 希望する最小の残り freshness は **min-fresh** で表し, **max-stale** ではありません. origin の厳しさと client の許容度の両方を見ると, cache policy を会話しやすくなります.

**Explanation:** write 系 endpoint を通した後に stale read が続く事故は, cache の存在を忘れた設計で起きやすいです. **unsafe method** は state 変更を起こし得る method です. **invalidation** は, その変更で怪しくなった stored response を使わないようにすることです. CMS, 管理画面, 商品編集, 設定変更 API の直後に「更新したのに画面が変わらない」問題として現れます. - A (incorrect): unsafe request の成功で, まだ fresh な stored response も不正確になり得るため, 元の lifetime では再利用を正当化できません. - B (incorrect): RFC 9111 が target URI に要求するのは invalidation であり, 古い response を短時間 valid のまま残すことではありません. - C (correct): invalidation では, matching stored response を削除するか invalid として扱い, 再利用前の validation を必須にします. cache invalidation が難しいのは, 更新対象 URI だけでなく関連一覧まで影響が広がることがあるからです.

**Explanation:** **Age** は見慣れないため, 単なる proxy のおまけ情報として見落とされがちです. **Age** は freshness 計算に使う指標で, origin 生成または成功 validation からの経過時間を見積もる助けになります. CDN debug, browser での残り freshness の読み取り, stale に近い response の説明で役立ちます. - A (correct): **Age** は, response が origin で生成または正常に validation されてからの推定秒数を伝えます. - B (incorrect): **Age** は現在の cache が受信する前の時間も含み, この cache だけの滞留時間ではありません. - C (incorrect): 残り freshness は freshness lifetime と current age から計算します. **Age** field が伝えるのは current age です. **Age** は freshness 計算を助けますが, それ単独で reuse 可否を決めるわけではありません.

**Explanation:** HEAD responseのmetadataは, representation bodyを転送せずにstored GET responseの状態を更新する手掛かりになります. **HEAD** は, equivalent な GET で返る header field を content なしで返します. 200 HEAD response を受けた cache は, 選択可能な stored GET response について validator と Content-Length が一致すれば update し, 一致しなければ stale とみなせます. 大きな object の存在確認, metadata refresh, monitoring で, 本体転送なしに状態を見たいときに使われます. - A (incorrect): 対象は HEAD request で選択可能な stored GET response に限られ, validator と Content-Length の条件も残ります. - B (correct): RFC 9111 は, HEAD request で選択可能だった stored GET response に対する条件付きの update または invalidation を定めています. - C (incorrect): HEAD response は replacement representation body を持たず, 一致する metadata で stored GET response を更新しても既存 body は消しません. すべての stored GET response を無条件に metadata refresh する機能ではありません. selection, validator, Content-Length の条件によって update するか stale とみなすかが決まります.

**Explanation:** validator の強さを理解しないと, semantic には同じでも byte 列としては別物, という差を扱えません. **strong validator** は representation の厳密な同一性を扱うのに向きます. **weak validator** は意味的に同じならよい場面向けです. artifact 配信, range request, resume download, 大きな binary の配布で重要です. - A (incorrect): weak ETag は意味的に同等な representation を識別できますが, range 結合に必要な strong identity は示しません. - B (incorrect): **Last-Modified** は自動的に strong validator になりません. strong-validation 条件を満たす根拠がなければ不十分です. - C (correct): strong ETag は strong validator であり, RFC 9111 は cache が結合する全 range に同じ strong validator を要求します. 「同じとみなせればよい」のか, 「完全に同じでないと困る」のかで validator の選び方が変わります.

**Explanation:** protocol directive を, logging, telemetry, analytics, app-level retention まで含めた万能保証だと誤解するのは危険です. **no-store** は cache に保存させないための指示です. それは強いですが, システム全体の痕跡ゼロ保証とは別です. security review, privacy 表現の確認, 法務や platform team との会話で, 過剰な保証文言を避けるために重要です. - A (incorrect): **no-store** が制約するのは conforming cache であり, application log・history・telemetry・非準拠 component の copy までは消去しません. - B (correct): **no-store** は cache 保存を強く制限しますが, RFC 9111 はそれだけで信頼できる十分な privacy mechanism にはならないと明記しています. - C (incorrect): **no-store** は private cache と shared cache の双方に適用され, conforming な intermediary cache も対象です. privacy 設計は HTTP header だけで完結せず, log と保存ポリシーまで含めて詰める必要があります.

**Explanation:** cache 事故の切り分けで, entry 選択ミスと stale 利用ミスを分けて考えられないと原因を外しやすいです. **Vary** は variant 選択, **ETag** は validation です. 判断フェーズがそもそも違います. 「別言語が出た」「正しい言語だけど古い内容だった」を切り分けるときに役立ちます. - A (correct): **Vary** は request field を stored-response matching に加え, **ETag** は選択後に origin state と条件付き比較するために使います. - B (incorrect): **ETag** は cache key を決めませんし, **Age** は validator でもありません. - C (incorrect): **private** は reuse 制限であって validation ではありません. cache は 1 回の判断ではなく, 「選ぶ」「freshness を見る」「必要なら validation する」という段階的な仕組みです.

**Explanation:** cache policyはstorage permission, freshness, validation, audienceをendpointの性質に合わせて組み合わせる必要があります. **public** は response を明示的に cacheable としますが, 通常の規則ですでに cacheable なら必須ではありません. **max-age=120** は freshness window を定めます. **no-store** と **private** は設問の shared-cache policy と衝突します. catalog, public listing, anonymous search API で, edge cache を使って負荷を落とすときの基本です. - A (correct): **public** は response を明示的に cacheable とし, 他の制約に従う shared cache での保存も許します. - B (incorrect): **no-store** は private cache と shared cache の双方で保存を禁止するため, 再利用の要件と衝突します. - C (correct): **max-age=120** は response の age が 120 秒を超えた後に stale とし, 求める freshness window を明示します. - D (incorrect): **private** は shared cache の保存を禁止するため, 設問の policy と衝突します. content が JSON か HTML かではなく, audience と mutation rate と stale 許容度で policy を決めるのが本筋です.

**Explanation:** heuristic freshnessを計算できるというprotocol上の許可と, 推定lifetimeがapplicationのvalidationなし再利用の上限を満たすかは別の問題です. 30秒という上限には明示的なresponse metadataが必要です. 明示的な expiration がない場合, cache は許可された条件下で **heuristic expiration time** を割り当てられます. ここでの 10% は cache の local policy であり, RFC 9111 が要求する計算法ではありません. 明示的な **max-age** は heuristic freshness より優先され, validator は response が stale になった後の conditional revalidation に使えます. legacy な在庫 service が freshness metadata を省略し, CDN が default の heuristic を補う構成で起こります. その default が service の上限を超えて validation なしの再利用を許すなら, application owner は明示的な policy に置き換える必要があります. - A (incorrect): RFC 9111 Section 4.2.2 が heuristic freshness を許す場合でも, local policy が算出した約 1 日という lifetime は application の 30 秒制限に違反します. - B (correct): `Cache-Control: max-age=30` は明示的に 30 秒の freshness lifetime を設定します. `Last-Modified` を維持すれば, stale になった後に conditional revalidation できます. - C (incorrect): `public` は response を cacheable にできますが, 30 秒の freshness lifetime は設定しません. 明示的な expiration がないため, local policy による約 1 日の heuristic が残り得ます. application が validation なしで再利用できる時間の上限を定めている場合, heuristic algorithm は明示的な freshness lifetime の代わりにはなりません.

**Explanation:** cache 候補の選定を, 「静的か動的か」だけで雑に分けると失敗しやすいです. **shared cache** は, 多くの client が同じ representation を安全に使い回せるほど価値が高いです. CDN の導入範囲を決めるときに, どこへ effort を払うべきかを判断する基本になります. - A (correct): version 付き asset は shared cache の定番です. - B (incorrect): session 依存 page は user 横断で再利用できません. - C (correct): 公開 documentation page は user 間で同じ content を返しやすく, shared caching に適しています. - D (correct): anonymous な商品一覧 response も, user 固有 data を含まなければ shared caching に適しています. shared cache 向きかどうかは, audience, 個人差分, 更新頻度, stale 許容度で見ると整理しやすいです.

**Explanation:** 304を受けたcacheはstored responseを捨てるのではなく, selected fieldを更新して再利用します. **304 Not Modified** は, 条件付き request の結果として「持っている body をそのまま使ってよい」と伝える応答です. browser の waterfall, reverse proxy の挙動確認, origin 負荷削減の検証で頻出です. - A (incorrect): 304 は body 置き換えのための full response ではありません. - B (correct): 304 は selected stored response を返された metadata で更新し, 既存の representation body とともに再利用できることを示します. - C (incorrect): 304 は response を永久に fresh にせず, 以後の validation や reuse の要件も取り除きません. conditional request の要点は, 正確さを落とさずに body 転送を減らすことです.

**Explanation:** A: RFC 9111 Section 3.5は, 許可directiveがある一部のauthenticated responseをshared cacheで再利用可能にします.Authorization自体は自動的なpartition keyではないため, このpolicyは個人向けrepresentationを露出させ得ます. B: Section 5.2.2.4のno-cacheは再利用条件であり, 保存禁止ではありません. C: 公開responseにはpublic, max-age=600, Vary: Accept-Languageとvalidatorを使えます. 個人向けresponseのno-storeは, Section 5.2.2.5によりconformingなprivate cacheとshared cacheへ保存しないよう指示します. representationまたはrouteを分け, 公開用policyを個人向けresponseへ適用させない設計が必要です. D: Section 5.2.2.7のprivateはshared cacheによる保存を防ぎますが, qualifierなしのprivate responseをbrowserのprivate cacheが保存することは許容します. 保存禁止要件を満たしません. 判定条件: まずrepresentation境界を定義し, その単位でstorage permission, cache key selection (Section 4.1), freshness, validationを決めます.