RFC 9111 Quiz

**Explanation:** Teams often treat every HTML page as just another cacheable document and forget that sensitivity matters more than latency on some endpoints. **no-store** tells conforming private and shared caches not to store the response. **private** prevents storage by shared caches but still allows a private cache such as a browser to store it. In practice this appears in reviews for account dashboards, admin consoles, and responses whose retention in a private HTTP cache or shared intermediary would create exposure. - A (incorrect): **public** is wrong for personalized financial data because shared caches must not reuse it across users. - B (incorrect): **private** prevents storage by shared caches but still permits storage in a browser's private cache, so it does not meet this requirement. - C (correct): **no-store** instructs conforming private and shared caches not to store the response, matching the stated cache-retention requirement. Caching is not only a performance decision. It is also a data-handling decision. RFC 9111 warns that no-store alone is not a reliable or sufficient privacy mechanism against malicious or compromised caches and network eavesdropping.

**Explanation:** Many production bugs come from confusing **no-cache** with **no-store**, which leads teams either to over-cache or to disable caching unnecessarily. **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**. In practice this matters for dashboards and APIs where you want conditional requests and bandwidth savings, but not blind reuse. - A (incorrect): **no-store** prohibits a cache from storing the response; **no-cache** does not impose that storage prohibition. - B (correct): A cache may store the response, but before reuse it must forward the request for origin validation and receive a successful response. - C (incorrect): Unqualified **no-cache** constrains reuse by both private and shared caches; it does not reserve reuse for private caches. Revalidation is often the right middle ground between “never store” and “reuse freely.”

**Explanation:** 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. **max-age** applies generally to caches. **s-maxage** is for **shared caches**, such as CDNs and proxy caches. This appears when you want edge caching to absorb load while browsers still re-check more aggressively because user-visible freshness matters. - 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. Split cache lifetimes are common in API and storefront design where origin load and user freshness have different tolerances.

**Explanation:** Mixed legacy and modern headers are common. Reviewers need to know which signal actually controls behavior instead of reasoning from both at once. **Cache-Control** is the primary HTTP caching control surface. **Expires** is an older absolute-time mechanism. You see this when frameworks add default headers, CDNs rewrite responses, or older services still emit legacy metadata. - A (correct): **max-age** is evaluated before **Expires** when calculating the freshness lifetime. - B (incorrect): A recipient must ignore **Expires** when the response includes **Cache-Control: max-age**. - C (incorrect): Freshness uses the specified precedence order; a cache does not select whichever value yields a longer lifetime. Prefer explicit, relative freshness policy with **Cache-Control**, because it is clearer and less fragile than clock-based reasoning alone.

**Explanation:** Caching discussions often mix up selection metadata, freshness metadata, and validation metadata. The distinction matters for correct debugging. **validators** let a cache ask whether a stored response still matches the current representation. **ETag** and **Last-Modified** are classic validator fields. This is central when troubleshooting unexpected **304 Not Modified** responses or excessive origin traffic from needless full downloads. - A (correct): **ETag** is a validator designed for conditional requests. - B (incorrect): **Age** estimates time since origin generation or successful validation; it does not compare a representation with current origin state. - C (correct): **Last-Modified** can also drive conditional revalidation. - D (incorrect): **Vary** nominates request fields that must match when selecting a stored response; it does not compare that response with current origin state. Selection, freshness, and validation are different phases of cache reasoning. Good debugging separates them.

**Explanation:** 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. **304 Not Modified** is a validation result. It says the cache can keep using the stored representation body. In practice this affects reverse proxies, browser devtools interpretation, and origin cost when tuning conditional GET behavior. - A (incorrect): The 304 supplies validation metadata, not an empty replacement representation; the cache keeps the selected stored body. - B (correct): The cache reuses the existing representation body and updates the applicable stored header fields with metadata from the validation response. - C (incorrect): The cache must update each identified stored response's header fields with applicable fields supplied by the 304 response. A successful validation path is often cheaper than a full **200** response, but it still depends on correct validator handling.

**Explanation:** Variant confusion is a classic cache bug. People often blame freshness when the real problem is cache key selection. **Vary** tells a cache which request fields influence representation selection. **Accept-Language** is commonly part of language negotiation. This shows up in multilingual sites, device-adaptive rendering, and compressed/uncompressed content delivery. - 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. **Vary** is about “which stored entry should I pick,” not “is the chosen entry still fresh.”

**Explanation:** “Authenticated” does not automatically mean “uncacheable,” but it does raise the bar. Engineers need to know the difference between default caution and explicit permission. A **shared cache** is reused across clients. For a request containing **Authorization**, RFC 9111 names **must-revalidate**, **public**, and **s-maxage** as response directives that permit shared caching, subject to each directive's requirements. This matters for CDNs in front of APIs, token-authenticated content, and service meshes that want to cache some authenticated traffic safely. - A (correct): **public** explicitly marks the response cacheable and permits shared caching of a response to an authenticated request. - B (incorrect): **private** prevents a shared cache from storing the response; it does not grant an authenticated-response exception. - C (correct): **s-maxage** permits shared caching while defining the shared-cache maximum age and requiring origin validation after staleness. - D (correct): **must-revalidate** permits shared caching but forbids stale reuse until origin validation succeeds. - E (incorrect): **no-store** prohibits storage by both private and shared caches. Security-sensitive caching decisions should be explicit in headers, not inferred from optimistic assumptions.

**Explanation:** Teams often reach for **private** when they mean “sensitive” or “must not be stored anywhere,” but that is not what the directive says. The unqualified **private** response directive means a shared cache must not store the response. A private cache can still store it subject to the normal caching constraints. This is common in user dashboards, personalized homepages, and BFF-style endpoints that are safe in a browser but not in a CDN. - A (incorrect): An **ETag** can support later validation, but the storage restriction imposed by **private** does not depend on a validator. - B (correct): Unqualified **private** prevents storage by shared caches while allowing a private cache to store the response subject to the normal constraints. - C (incorrect): Validation before every reuse is the role of unqualified **no-cache**; **private** instead controls storage scope. If persistence in conforming private caches is also unacceptable, **no-store** is the stronger instruction. Neither directive guarantees message confidentiality.

**Explanation:** Shared reuse is safe only when the representation is user-independent, stable for the stated lifetime, and suitable for retention outside the origin. **public** explicitly allows storage by shared caches. Versioned static assets are usually excellent shared-cache candidates because identity and mutability are controlled. CDNs, image delivery, and immutable build artifacts all benefit from clear public cacheability. - 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. “Same URI for everyone” is not enough. You also need stable content and low confidentiality risk.

**Explanation:** Engineers often underestimate the business impact of stale data, especially for inventory, quota, or compliance decisions. **must-revalidate** means that once the response becomes stale, a cache cannot keep serving it without successful validation. This matters for stock counts, entitlement decisions, feature gates, and financial limits where stale data can cause incorrect actions. - A (incorrect): **no-store** prohibits storage, which is stronger than the stated policy and removes the intended fresh reuse. - B (incorrect): **public** changes cacheability, but it does not impose the required origin validation after the response becomes stale. - C (correct): **must-revalidate** does not prohibit storage or fresh reuse, but once stale the response cannot be reused until origin validation succeeds. Freshness lifetime answers “how long may I reuse this.” Revalidation directives answer “what happens after that time runs out.”

**Explanation:** Teams sometimes assume “no freshness header” means “never cached,” but caches can still reason heuristically in some cases. **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. This appears with legacy services, static pages missing explicit cache headers, and CDN defaults in front of older origins. - A (incorrect): Becoming stale does not itself authorize a new heuristic lifetime; the original freshness lifetime might have been explicit. - B (correct): When explicit expiration is absent and the response is heuristically cacheable, a cache may assign a heuristic freshness lifetime. - C (incorrect): A validator supports revalidation but does not trigger heuristic freshness, especially when an explicit lifetime already applies. Heuristic caching is a fallback, not a substitute for deliberate cache policy.

**Explanation:** Client request directives are less famous than response directives, so they are easy to misuse in proxy and browser tooling. **min-fresh** is a request preference. It asks for a response that will still be fresh for at least the given number of seconds. This can matter for prefetching, offline-aware clients, and workflows where a response must stay usable for a near-future action. - A (correct): **min-fresh=N** expresses a preference for a response whose freshness lifetime exceeds its current age by at least N more seconds. - B (incorrect): An acceptable amount of staleness is expressed by **max-stale**, not **min-fresh**. - C (incorrect): **min-fresh** constrains the desired remaining freshness; it does not postpone or forbid validation. Client directives are about preferences and constraints on reuse, not about rewriting origin policy.

**Explanation:** Engineers often learn only origin-side directives and forget that clients can also express reuse preferences. **max-stale** is a request directive that says the client can tolerate some staleness. It can be unbounded or bounded by a value. This matters for resilient clients, degraded-mode browsing, and systems that value availability over perfect freshness in some workflows. - A (incorrect): The **max-age** request directive constrains acceptable response age; it does not express willingness to accept staleness. - B (correct): With a value, **max-stale** bounds how far past freshness the response may be; without one, the client accepts staleness of any age. - C (incorrect): A minimum remaining freshness interval is expressed by **min-fresh**, not **max-stale**. Freshness policy is a negotiation between origin instructions and client tolerance, not a one-sided command channel.

**Explanation:** Caches are not just passive readers. Unsafe methods can make previously stored responses wrong immediately. An **unsafe method** can change server state. **invalidation** means dropping or retiring stored responses that may no longer reflect current origin state. This is critical after writes in APIs, CMS systems, admin panels, and any product where a fresh read is expected right after an update. - A (incorrect): A successful unsafe request can make a still-fresh stored response incorrect, so its prior freshness lifetime cannot justify continued reuse. - B (incorrect): RFC 9111 requires invalidation of the target URI, not merely a shorter period in which the old response remains valid. - C (correct): Invalidation means removing matching stored responses or marking them invalid so they require validation before reuse. Cache invalidation is hard mainly because the dependency graph can be broader than the directly updated URI.

**Explanation:** People often treat **Age** as a mystery proxy field, but it is a practical signal for understanding freshness calculations. **Age** estimates how much time has passed since the response was generated or successfully validated by the origin, as seen through caching layers. You read **Age** when debugging CDN behavior, explaining why a response is already close to expiry, or checking whether revalidation is working. - A (correct): **Age** conveys the sender's estimate of seconds since the response was generated or successfully validated at the origin. - B (incorrect): **Age** includes time before the current cache received the response; it is not only this cache's residence time. - C (incorrect): Remaining freshness is calculated from freshness lifetime and current age; the **Age** field reports current age, not the remaining interval. **Age** affects freshness math, but it does not by itself decide whether a response may be reused.

**Explanation:** HEAD is often taught as a curiosity, but it matters when thinking about cheap metadata refresh and cache bookkeeping. **HEAD** returns the headers that would accompany an equivalent GET response without content. After a 200 HEAD response, a cache can update matching selectable GET responses or mark them stale when validators or Content-Length do not match. This can matter for large objects, CDN metadata refresh, and monitoring systems that need state hints without full download cost. - A (incorrect): Only stored GET responses selectable for the HEAD request are considered, and their validators and Content-Length still govern the result. - B (correct): RFC 9111 defines this conditional update-or-invalidate behavior for stored GET responses that could have been selected for the HEAD request. - C (incorrect): A HEAD response has no replacement representation body; matching metadata can update a stored GET response without erasing its body. This is not an unconditional metadata refresh for every stored GET response. Selection, validator, and Content-Length conditions determine whether a stored response is updated or considered stale.

**Explanation:** Validator strength matters when caches or clients need confidence about exact representation identity, not just approximate sameness. A **strong validator** supports exact representation matching. A **weak validator** is looser and better for semantic equivalence than byte identity. This matters for range requests, resumable downloads, artifact delivery, and any flow where exact bytes are important. - A (incorrect): A weak ETag can identify semantically equivalent representations but does not establish the strong identity required to combine ranges. - B (incorrect): **Last-Modified** is not automatically a strong validator; without evidence that it meets strong-validation rules, it is insufficient here. - C (correct): A strong ETag is a strong validator, which RFC 9111 requires all ranges to share before a cache combines them. Good cache design starts by asking what kind of equality the client actually needs.

**Explanation:** Security reviews go wrong when people over-interpret protocol directives as end-to-end guarantees that cover logs, telemetry, and every implementation detail. **no-store** is a cache directive. It tells caches not to keep a stored copy. It does not magically erase every other system artifact. This matters when discussing privacy claims with legal, security, or platform teams. Protocol behavior and system-wide data retention are different layers. - A (incorrect): **no-store** constrains conforming caches; it does not erase application logs, history mechanisms, telemetry, or copies retained by nonconforming components. - B (correct): **no-store** strongly restricts cache storage, but RFC 9111 explicitly says it is not a reliable or sufficient privacy mechanism by itself. - C (incorrect): The directive applies to both private and shared caches, including conforming intermediary caches. Good privacy design combines protocol directives with logging, retention, and storage controls outside HTTP caching itself.

**Explanation:** Cache failures are easier to diagnose when you know whether the bug happened during entry selection or after selection during reuse checks. **Vary** shapes cache key selection. **ETag** is a validator used after the cache has already chosen a stored response candidate. In practice, this distinction helps when debugging “wrong variant served” versus “right variant served but not fresh anymore.” - A (correct): **Vary** adds nominated request fields to stored-response matching, while **ETag** supports a conditional comparison with origin state after selection. - 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. Good cache design has multiple decision stages. Mixing them together leads to cargo-cult reasoning.

**Explanation:** A cache policy must combine storage permission, freshness, validation, and audience instead of treating each directive in isolation. **public** explicitly marks a response cacheable, although it is unnecessary when the response is already cacheable under the normal rules. **max-age=120** sets the freshness window. **private** and **no-store** conflict with the stated shared-cache policy. This is exactly the kind of quick policy choice engineers make for catalog APIs, anonymous landing data, and search suggestion payloads. - A (correct): **public** explicitly marks the response as cacheable, including by a shared cache subject to the other caching constraints. - B (incorrect): **no-store** contradicts the requirement to reuse for 120 seconds. - C (correct): **max-age=120** makes the response stale after its age exceeds 120 seconds, supplying the requested explicit freshness window. - D (incorrect): **private** would block shared-cache reuse and conflict with the public API goal. Cache policy should reflect data audience, mutation rate, and harm if stale, not just “is it JSON or HTML.”

**Explanation:** Permission to calculate heuristic freshness does not mean that the inferred lifetime satisfies the application's unvalidated-reuse limit. A 30-second limit therefore needs explicit response metadata. A cache can assign a **heuristic expiration time** in permitted cases when no explicit expiration is available. The 10% calculation in this scenario is the cache's local policy, not a rule required by RFC 9111. An explicit **max-age** takes precedence over heuristic freshness, while a validator supports conditional revalidation after the response becomes stale. This arises when a legacy inventory service omits freshness metadata and a CDN supplies a default heuristic. The application owner must replace that default when it permits unvalidated reuse beyond the service's limit. - A (incorrect): RFC 9111 Section 4.2.2 can permit heuristic freshness, but the local one-day result still violates the application's 30-second limit. - B (correct): `Cache-Control: max-age=30` sets an explicit 30-second freshness lifetime. Retaining `Last-Modified` allows conditional revalidation after the response becomes stale. - C (incorrect): `public` can make a response cacheable, but it does not set a 30-second freshness lifetime. With no explicit expiration, the local one-day heuristic remains possible. A heuristic algorithm is deployment policy, not a substitute for an explicit freshness lifetime when the application defines a maximum unvalidated-reuse window.

**Explanation:** Shared caching works best when audience and representation are stable. Many bad policies come from ignoring either one. A **shared cache** is worthwhile when many users can safely reuse the same representation. The opposite is session-bound or user-specific content. This question maps directly to CDN onboarding, edge policy reviews, and deciding which endpoints deserve cache effort. - 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. Good shared-cache candidates are public, broadly reused, and not overly sensitive to short staleness.

**Explanation:** Even experienced engineers sometimes remember **304** only as “a cache status code” without understanding the operational consequences. **304 Not Modified** means the cache’s stored representation is still valid for reuse after conditional revalidation. This affects browser waterfall analysis, CDN origin traffic, and server-side conditional request implementations. - A (incorrect): **304** does not carry the stored representation body as a replacement payload. - B (correct): A 304 tells the cache that the selected stored response can be updated with returned metadata and reused with its existing representation body. - C (incorrect): A 304 neither makes the response permanently fresh nor removes the need to satisfy future validation and reuse requirements. Conditional requests are valuable mainly because they preserve correctness while reducing transfer cost.

**Explanation:** A: RFC 9111 Section 3.5 permits some authenticated responses to be shared when an enabling directive is present; Authorization is not an automatic partition key. This policy can expose the personalized representation. B: Section 5.2.2.4 defines no-cache as a reuse constraint, not a storage prohibition. C: The public response can use public, max-age=600, Vary: Accept-Language, and validators. The personalized response uses no-store, which Section 5.2.2.5 directs conforming private and shared caches not to store. Separate representation or route handling prevents the public cache policy from being applied to it. D: Section 5.2.2.7 prevents shared-cache storage, but a private browser cache may store an unqualified private response. That fails the stated no-storage requirement. Decision rule: Define the representation boundary first, then apply storage permission, cache-key selection (Section 4.1), freshness, and validation to that representation.