After a successful PUT to a Cisco resource, a follow-up GET returns 200 with a different ETag than the client had cached. What should happen to the old stored body?
Select an answer to reveal the explanation.
Short Explanation
A new coat-check number means the old stub is retired. When the ETag changes after a write or a fresh 200, drop or replace the old body—clinging to it is a stale-read bug, not an optimization.
Full Explanation
After a successful PUT, validators and bodies move forward. When a follow-up GET returns 200 with a different ETag than the client had cached, the old stored body is no longer the representation that matches current validators. The consumer must invalidate or replace the previous cached representation so later reads and conditional requests use the new content and ETag. Otherwise municipal automation keeps reasoning about a pre-write configuration.
Keeping serving the old body indefinitely because bandwidth optimization prefers never discarding cache fails correctness: bandwidth savings never justify serving the wrong inventory. Ignoring the new ETag and continuing conditional requests with the outdated validator only fails because If-None-Match with a stale ETag may incorrectly 304 against a server that already moved on—or force unnecessary full downloads inconsistently. Converting the new ETag into a max-age of zero and stopping all further caching for every URL overreacts: only that resource’s cache entry needs refresh, not a global cache ban.
Exam caveat: some clients update cache from the PUT response itself when it carries a new ETag and body; a confirming GET that shows a new ETag still requires replacing the old entry. Unsafe methods should trigger invalidation of related cached GETs.
Operational check: after PUT, confirm the cache key for that resource holds the new ETag/body, and that the next conditional GET uses the updated validator rather than the pre-PUT ETag.