A Cisco API response includes Expires and Age headers alongside usable Cache-Control. How should a consumer use Expires and Age?
Select an answer to reveal the explanation.
Short Explanation
Expires is the “best by” date; Age is how long the carton has already sat on the shelf. They help you skip a needless trip—but they never trump an explicit no-store, and Cache-Control still leads when both speak.
Full Explanation
Expires and Age are HTTP freshness inputs. When a Cisco API response includes Expires and Age alongside usable Cache-Control, the consumer should use them as freshness calculations that can skip a redundant GET—while preferring Cache-Control when directives conflict, and never using Expires/Age to justify unsafe storage of no-store or privileged bodies. Age indicates how long the response has been resident in a cache path; Expires gives an absolute expiry instant.
Letting Expires override an explicit no-store so privileged bodies can be written to disk fails priority and security: no-store wins over convenience freshness. Ignoring Expires and Age completely whenever any Cisco product name appears in the URL fails without cause—standard HTTP caching still applies to Cisco REST unless a stronger directive forbids storage. Treating Age as a command to delete the cache entry immediately regardless of freshness misreads Age; it is an input to freshness lifetime, not an instant purge signal.
Exam caveat: HTTP caching prefers Cache-Control over Expires when both are present and conflict. Age from intermediaries matters for shared caches calculating remaining freshness.
Operational check: compute remaining freshness from max-age/Expires minus Age in a staging cache, confirm a GET is skipped while fresh, and confirm no-store responses remain unstored even if Expires looks far in the future.