A response from a Cisco health API includes Cache-Control: no-cache. What does that directive mean for the consumer’s stored copy?
Select an answer to reveal the explanation.
Short Explanation
no-cache is “show your ticket again before you sit,” not “throw the ticket away.” You may keep a copy, but revalidate with the origin before treating it as fresh—unlike no-store, which forbids keeping it.
Full Explanation
Municipal health-check consumers should treat Cache-Control: no-cache as a revalidation rule, not a delete rule. The client may keep a stored copy of the Cisco health representation, but before presenting that copy as fresh it must revalidate with the origin—typically with a conditional request using ETag or Last-Modified. That cheap validator hop avoids blind reuse of stale municipal status while still allowing local storage for latency and resilience.
Treating no-cache as “never write the representation to any storage” fails the HTTP semantics: that meaning belongs to no-store. Serving stored bytes as fresh forever without contacting the origin fails because it ignores the mandatory revalidation obligation and can show outdated controller or platform health to city operators. Claiming the directive applies only to CDNs and can be ignored by application clients fails because Cache-Control is a shared caching protocol for any conforming consumer, including civic API clients and intermediate caches.
Exam caveat: no-cache ≠ no-store. no-store forbids retaining the representation; no-cache permits storage but requires origin contact before reuse as fresh. max-age and must-revalidate are related but not interchangeable with this stem’s directive.
Operational check: capture a health response that carries Cache-Control: no-cache, confirm the municipal client stores the body, then on the next read verify a conditional revalidation (If-None-Match / If-Modified-Since) reaches the origin before the UI treats the copy as fresh.