RFC 9111 Quiz

**Explanation:** **Context (why chosen):** Teams often treat every HTML page as just another cacheable document and forget that sensitivity matters more than latency on some endpoints. **Terms:** **no-store** means caches should not keep a copy. **private** limits reuse to a private cache such as a browser, but it still allows storage. **Real-world usage:** In practice this appears in reviews for account dashboards, admin consoles, and pages that can leak personal data through browser history or shared devices. **Options:** - A (incorrect): **public** is wrong for personalized financial data because shared caches must not reuse it across users. - B (incorrect): **private** avoids shared-cache reuse, but it still permits storage in the browser and is weaker than needed for highly sensitive content. - C (correct): **no-store** matches the risk model when persistence itself is unacceptable. **Related:** Caching is not only a performance decision. It is also a data-handling and privacy decision.

**Explanation:** **Context (why chosen):** Many production bugs come from confusing **no-cache** with **no-store**, which leads teams either to over-cache or to disable caching unnecessarily. **Terms:** **no-cache** does not mean “do not cache.” It means a stored response must be validated before reuse. **validation** usually uses validators such as **ETag** or **Last-Modified**. **Real-world usage:** In practice this matters for dashboards and APIs where you want conditional requests and bandwidth savings, but not blind reuse. **Options:** - A (incorrect): That is the meaning of **no-store**, not **no-cache**. - B (correct): Storage is allowed, but reuse requires an origin check. - C (incorrect): This answer invents a private-cache-only rule that **no-cache** does not define. **Related:** Revalidation is often the right middle ground between “never store” and “reuse freely.”

**Explanation:** **Context (why chosen):** Shared caches and private caches often need different reuse windows, but teams frequently publish a single directive and hope every layer behaves the same way. **Terms:** **max-age** applies generally to caches. **s-maxage** is for **shared caches**, such as CDNs and proxy caches. **Real-world usage:** This appears when you want edge caching to absorb load while browsers still re-check more aggressively because user-visible freshness matters. **Options:** - A (incorrect): This gives both browsers and shared caches the same 10-minute lifetime. - B (correct): Browsers get 60 seconds, while shared caches can reuse for 600 seconds. - C (incorrect): **private** blocks shared-cache reuse, which defeats the CDN goal. **Related:** Split cache lifetimes are common in API and storefront design where origin load and user freshness have different tolerances.

**Explanation:** **Context (why chosen):** Mixed legacy and modern headers are common. Reviewers need to know which signal actually controls behavior instead of reasoning from both at once. **Terms:** **Cache-Control** is the primary HTTP caching control surface. **Expires** is an older absolute-time mechanism. **Real-world usage:** You see this when frameworks add default headers, CDNs rewrite responses, or older services still emit legacy metadata. **Options:** - A (correct): **Cache-Control** takes precedence when both are present. - B (incorrect): **Expires** does not win over explicit **Cache-Control** freshness directives. - C (incorrect): Caches do not pick the more convenient lifetime based on length. **Related:** Prefer explicit, relative freshness policy with **Cache-Control**, because it is clearer and less fragile than clock-based reasoning alone.

**Explanation:** **Context (why chosen):** Caching discussions often mix up selection metadata, freshness metadata, and validation metadata. The distinction matters for correct debugging. **Terms:** **validators** let a cache ask whether a stored response still matches the current representation. **ETag** and **Last-Modified** are classic validator fields. **Real-world usage:** This is central when troubleshooting unexpected **304 Not Modified** responses or excessive origin traffic from needless full downloads. **Options:** - A (correct): **ETag** is a validator designed for conditional requests. - B (incorrect): **Age** reports how long a response has been in cache, not whether it still matches origin state. - C (correct): **Last-Modified** can also drive conditional revalidation. - D (incorrect): **Vary** affects cache key selection, not validation. **Related:** Selection, freshness, and validation are different phases of cache reasoning. Good debugging separates them.

**Explanation:** **Context (why chosen):** Teams sometimes treat **304** as if it were a body-carrying success response or as if it invalidated the cached entry. Both interpretations are wrong. **Terms:** **304 Not Modified** is a validation result. It says the cache can keep using the stored representation body. **Real-world usage:** In practice this affects reverse proxies, browser devtools interpretation, and origin cost when tuning conditional GET behavior. **Options:** - A (incorrect): The stored body is exactly what the cache is supposed to keep using. - B (correct): The cache reuses the existing representation and may update metadata supplied with the validation response. - C (incorrect): **304** is about validation, not location change. **Related:** A successful validation path is often cheaper than a full **200** response, but it still depends on correct validator handling.

**Explanation:** **Context (why chosen):** Variant confusion is a classic cache bug. People often blame freshness when the real problem is cache key selection. **Terms:** **Vary** tells a cache which request fields influence representation selection. **Accept-Language** is commonly part of language negotiation. **Real-world usage:** This shows up in multilingual sites, device-adaptive rendering, and compressed/uncompressed content delivery. **Options:** - A (correct): Without **Vary: Accept-Language**, a cache can wrongly reuse one language variant for another request. - B (incorrect): **Age** does not decide variant selection. - C (incorrect): **Last-Modified** helps validation, not language-based cache key separation. **Related:** **Vary** is about “which stored entry should I pick,” not “is the chosen entry still fresh.”

**Explanation:** **Context (why chosen):** “Authenticated” does not automatically mean “uncacheable,” but it does raise the bar. Engineers need to know the difference between default caution and explicit permission. **Terms:** A **shared cache** is a cache reused across clients. **Authorization** changes the default safety assumptions because responses are often user-specific. **Real-world usage:** This matters for CDNs in front of APIs, token-authenticated content, and service meshes that want to cache some authenticated traffic safely. **Options:** - A (incorrect): Speed alone is not a caching policy. Reuse must be explicitly safe. - B (incorrect): RFC 9111 allows exceptions when the response explicitly authorizes shared-cache reuse. - C (correct): Shared reuse requires explicit permission, not guesswork. **Related:** Security-sensitive caching decisions should be explicit in headers, not inferred from optimistic assumptions.

**Explanation:** **Context (why chosen):** Teams often reach for **private** when they mean “sensitive” or “must not be stored anywhere,” but that is not what the directive says. **Terms:** **private** restricts shared-cache storage and reuse. It does not automatically forbid a browser from storing the response. **Real-world usage:** This is common in user dashboards, personalized homepages, and BFF-style endpoints that are safe in a browser but not in a CDN. **Options:** - A (incorrect): Validators are unrelated to the meaning of **private**. - B (correct): The core meaning is “not for shared reuse.” - C (incorrect): Revalidation-on-every-use is closer to **no-cache** behavior. **Related:** If browser persistence is also unacceptable, **no-store** is usually the stronger and more appropriate instruction.

**Explanation:** **Context (why chosen):** The important skill is not memorizing directive names. It is identifying when reuse across users is actually safe. **Terms:** **public** explicitly allows storage by shared caches. Versioned static assets are usually excellent shared-cache candidates because identity and mutability are controlled. **Real-world usage:** CDNs, image delivery, and immutable build artifacts all benefit from clear public cacheability. **Options:** - A (correct): A versioned, user-independent asset is ideal for shared reuse. - B (incorrect): Personalized content should not be exposed to shared reuse. - C (incorrect): Security-sensitive transactional responses are poor candidates for public caching. **Related:** “Same URI for everyone” is not enough. You also need stable content and low confidentiality risk.

**Explanation:** **Context (why chosen):** Engineers often underestimate the business impact of stale data, especially for inventory, quota, or compliance decisions. **Terms:** **must-revalidate** means that once the response becomes stale, a cache cannot keep serving it without successful validation. **Real-world usage:** This matters for stock counts, entitlement decisions, feature gates, and financial limits where stale data can cause incorrect actions. **Options:** - A (incorrect): Storage can still happen. The directive controls stale reuse, not storage itself. - B (incorrect): Shared-cache permission is a different concern. - C (correct): The point is to stop “just serve stale and hope” behavior. **Related:** Freshness lifetime answers “how long may I reuse this.” Revalidation directives answer “what happens after that time runs out.”

**Explanation:** **Context (why chosen):** Teams sometimes assume “no freshness header” means “never cached,” but caches can still reason heuristically in some cases. **Terms:** **heuristic caching** estimates freshness when explicit freshness data is missing. That does not mean “invent anything you want”; it operates within defined limits and response categories. **Real-world usage:** This appears with legacy services, static pages missing explicit cache headers, and CDN defaults in front of older origins. **Options:** - A (incorrect): **no-store** explicitly blocks storage, so heuristics are irrelevant. - B (correct): This is the situation where heuristic freshness can matter. - C (incorrect): Authorization is unrelated to the definition of heuristic freshness. **Related:** Heuristic caching is a fallback, not a substitute for deliberate cache policy.

**Explanation:** **Context (why chosen):** Client request directives are less famous than response directives, so they are easy to misuse in proxy and browser tooling. **Terms:** **min-fresh** is a request preference. It asks for a response that will still be fresh for at least the given number of seconds. **Real-world usage:** This can matter for prefetching, offline-aware clients, and workflows where a response must stay usable for a near-future action. **Options:** - A (correct): That is the core meaning of **min-fresh**. - B (incorrect): Accepting stale content maps more closely to **max-stale** reasoning. - C (incorrect): Validators are unrelated to **min-fresh**. **Related:** Client directives are about preferences and constraints on reuse, not about rewriting origin policy.

**Explanation:** **Context (why chosen):** Engineers often learn only origin-side directives and forget that clients can also express reuse preferences. **Terms:** **max-stale** is a request directive that says the client can tolerate some staleness. It can be unbounded or bounded by a value. **Real-world usage:** This matters for resilient clients, degraded-mode browsing, and systems that value availability over perfect freshness in some workflows. **Options:** - A (incorrect): That is the opposite of what **max-stale** expresses. - B (correct): The directive widens the acceptable freshness window from the client side. - C (incorrect): Caches are not forced to keep responses forever. **Related:** Freshness policy is a negotiation between origin instructions and client tolerance, not a one-sided command channel.

**Explanation:** **Context (why chosen):** Caches are not just passive readers. Unsafe methods can make previously stored responses wrong immediately. **Terms:** An **unsafe method** can change server state. **invalidation** means dropping or retiring stored responses that may no longer reflect current origin state. **Real-world usage:** This is critical after writes in APIs, CMS systems, admin panels, and any product where a fresh read is expected right after an update. **Options:** - A (incorrect): Revalidation is a safe follow-up action, not the mistake. - B (incorrect): Invalidating stale knowledge is exactly what a good cache should consider. - C (correct): Reusing obviously stale state after a successful write defeats the correctness goal of caching. **Related:** Cache invalidation is hard mainly because the dependency graph can be broader than the directly updated URI.

**Explanation:** **Context (why chosen):** People often treat **Age** as a mystery proxy field, but it is a practical signal for understanding freshness calculations. **Terms:** **Age** estimates how much time has passed since the response was generated or successfully validated by the origin, as seen through caching layers. **Real-world usage:** You read **Age** when debugging CDN behavior, explaining why a response is already close to expiry, or checking whether revalidation is working. **Options:** - A (correct): This is the useful interpretation for freshness reasoning. - B (incorrect): **Age** is not a hop count. - C (incorrect): Validator preference is unrelated to **Age**. **Related:** **Age** affects freshness math, but it does not by itself decide whether a response may be reused.

**Explanation:** **Context (why chosen):** HEAD is often taught as a curiosity, but it matters when thinking about cheap metadata refresh and cache bookkeeping. **Terms:** **HEAD** returns the headers that would accompany a GET response, without the response body. That makes it useful for metadata-oriented checks. **Real-world usage:** This can matter for large objects, CDN metadata refresh, and monitoring systems that need state hints without full download cost. **Options:** - A (incorrect): HEAD does not transfer the representation body. - B (correct): Metadata can be refreshed or compared while avoiding the full payload. - C (incorrect): HEAD does not redefine validator strength. **Related:** Even when HEAD is supported, you still need to reason carefully about which stored metadata remains trustworthy.

**Explanation:** **Context (why chosen):** Validator strength matters when caches or clients need confidence about exact representation identity, not just approximate sameness. **Terms:** A **strong validator** supports exact representation matching. A **weak validator** is looser and better for semantic equivalence than byte identity. **Real-world usage:** This matters for range requests, resumable downloads, artifact delivery, and any flow where exact bytes are important. **Options:** - A (incorrect): Weak validators are not the safest choice for exact byte-identity use cases. - B (incorrect): **Last-Modified** is not automatically stronger than an **ETag**. - C (correct): Exact identity-sensitive scenarios call for strong validation. **Related:** Good cache design starts by asking what kind of equality the client actually needs.

**Explanation:** **Context (why chosen):** Security reviews go wrong when people over-interpret protocol directives as end-to-end guarantees that cover logs, telemetry, and every implementation detail. **Terms:** **no-store** is a cache directive. It tells caches not to keep a stored copy. It does not magically erase every other system artifact. **Real-world usage:** This matters when discussing privacy claims with legal, security, or platform teams. Protocol behavior and system-wide data retention are different layers. **Options:** - A (incorrect): That promise is broader than what the directive defines. - B (correct): This is the safe, engineering-accurate interpretation. - C (incorrect): Intermediaries are exactly part of the caching story. **Related:** Good privacy design combines protocol directives with logging, retention, and storage controls outside HTTP caching itself.

**Explanation:** **Context (why chosen):** Cache failures are easier to diagnose when you know whether the bug happened during entry selection or after selection during reuse checks. **Terms:** **Vary** shapes cache key selection. **ETag** is a validator used after the cache has already chosen a stored response candidate. **Real-world usage:** In practice, this distinction helps when debugging “wrong variant served” versus “right variant served but not fresh anymore.” **Options:** - A (correct): This cleanly separates selection from validation. - B (incorrect): **ETag** is not a cache-key selector, and **Age** is not a validator. - C (incorrect): **private** is a storage/reuse restriction, not a freshness validator. **Related:** Good cache design has multiple decision stages. Mixing them together leads to cargo-cult reasoning.

**Explanation:** **Context (why chosen):** The useful skill is mapping endpoint behavior to policy, not memorizing isolated directives. **Terms:** **public** permits shared reuse. **max-age=120** gives the freshness window. **private** and **no-store** push in the opposite direction. **Real-world usage:** This is exactly the kind of quick policy choice engineers make for catalog APIs, anonymous landing data, and search suggestion payloads. **Options:** - A (correct): Shared caches may reuse the response. - B (incorrect): **no-store** contradicts the requirement to reuse for 120 seconds. - C (correct): This supplies the desired freshness lifetime. - D (incorrect): **private** would block shared-cache reuse and conflict with the public API goal. **Related:** Cache policy should reflect data audience, mutation rate, and harm if stale, not just “is it JSON or HTML.”

**Explanation:** **Context (why chosen):** Heuristic caching is not inherently wrong. The key question is whether guessed freshness is acceptable for the data and the failure mode. **Terms:** **heuristic caching** estimates freshness in the absence of explicit cache lifetime metadata. That makes risk analysis especially important. **Real-world usage:** You encounter this when older services omit headers and platform teams must decide whether default CDN behavior is safe. **Options:** - A (incorrect): A low-change brochure page is a much safer place for heuristic reuse. - B (incorrect): Generic missing-page responses are often lower risk than dynamic transactional data. - C (correct): Business-critical, fast-changing inventory is a poor place for guessed freshness. **Related:** When stale risk is costly, explicit cache policy is much better than heuristic fallback.

**Explanation:** **Context (why chosen):** Shared caching works best when audience and representation are stable. Many bad policies come from ignoring either one. **Terms:** A **shared cache** is worthwhile when many users can safely reuse the same representation. The opposite is session-bound or user-specific content. **Real-world usage:** This question maps directly to CDN onboarding, edge policy reviews, and deciding which endpoints deserve cache effort. **Options:** - A (correct): Versioned static assets are classic high-value shared-cache targets. - B (incorrect): Session-bound pages should not be reused across users. - C (correct): Public docs are often stable, public, and broadly reusable. - D (correct): Anonymous catalog data is often safe and valuable to share-cache. **Related:** Good shared-cache candidates are public, broadly reused, and not overly sensitive to short staleness.

**Explanation:** **Context (why chosen):** Even experienced engineers sometimes remember **304** only as “a cache status code” without understanding the operational consequences. **Terms:** **304 Not Modified** means the cache’s stored representation is still valid for reuse after conditional revalidation. **Real-world usage:** This affects browser waterfall analysis, CDN origin traffic, and server-side conditional request implementations. **Options:** - A (incorrect): **304** does not carry the stored representation body as a replacement payload. - B (correct): Validation succeeded, so the stored body remains the active representation. - C (incorrect): Validator-free permanent cacheability is not what **304** means. **Related:** Conditional requests are valuable mainly because they preserve correctness while reducing transfer cost.

**Explanation:** **Context (why chosen):** The real goal of this RFC is better engineering judgment, not rote directive recall. **Terms:** A sound cache review covers **storage scope**, **freshness lifetime**, and **validation strategy**. Those are the three recurring decision points behind most real incidents. **Real-world usage:** This is the kind of comment you want in API reviews, CDN change reviews, and security sign-off discussions. **Options:** - A (correct): This frames the problem in the right dimensions and invites an explicit policy. - B (incorrect): Content type does not determine safe caching policy. - C (incorrect): Guesswork is exactly what RFC 9111 is trying to reduce through explicit behavior. **Related:** Mature caching practice is a design discipline. It combines semantics, risk tolerance, and deployment knowledge.