WEB / CASE cache-and-personalization
Whose representation is the cache hit?
Compare cache keys, freshness and authorization for a public catalogue and personalized responses.
Observation file
The synthetic public catalogue carries Cache-Control: public, max-age=60 and an ETag. A separate protected profile fixture carries Cache-Control: private, no-store. These are different cache policies and different resources.
Freshness is not access permission
ETag is a representation validator, not an identity or authorization decision. A 304 relates to a cached body; it does not show a new body delivered to everyone. Inspect the key and Vary for the correct context and variant.
A cache hit is not inherently abnormal. Reuse is expected for the same public representation. Applying the public catalogue baseline to a profile produces false conclusions.
Evidence for the correction
Verify fresh, stale and revalidated catalogue branches separately from profile caching and server authorization. A no-store header does not prove all older cached entries were removed or that application caches use the same policy.
YOUR TURN
Work through this story.
Predict the outcome, find the evidence boundary, and explain it in your own words.
Compare the public catalogue validator with the protected profile cache policy. Which access outcome is not established by these records?
Selected observations from the synthetic case file
- public catalogue Cache-Control
- public, max-age=60
- public catalogue validator
- ETag present
- protected profile Cache-Control
- private, no-store
- The ETag does not establish identity or object authorization for the profile.
- Both resources use the same cache policy.
- no-store proves that every past cached entry was deleted.
Read the explained answer
The ETag does not establish identity or object authorization for the profile. — Interpret cache results only with the resource and cache owner identified. ETag, cache policy and authorization are not interchangeable; observed no-store does not verify the entire cache history.
A cache hit is observed for the same public catalogue representation. What is missing before reporting personalized-data sharing?
- Every cache hit contains another user’s body.
- Evidence is needed for a personalized resource/body and an incorrect context/variant match.
- The presence of an ETag is a leaked session credential.
Read the explained answer
Evidence is needed for a personalized resource/body and an incorrect context/variant match. — Avoid a false conclusion by preserving the hit’s resource/context scope. Normal public reuse and protected personalized responses need distinct baselines and evidence.
Split the regression plan into catalogue and profile branches. What limits do you record for 304 and no-store observations?
Read the explained answer
Compare fresh, stale and revalidated catalogue branches for the correct representation/key/Vary context. A 304 relates to an existing cached body; do not claim a new body for everyone. In the profile branch, check private/no-store policy separately from server authorization. Do not extend one header observation into proof that every old entry was removed or that application caching follows the same policy. Identify the cache owner and observation source for each finding.
□ Are fresh/stale/revalidated catalogue branches separated with the correct variant context?
□ Is the 304 linked to the cached body?
□ Are profile cache policy and server authorization checked separately?
□ Does the plan avoid assuming past-entry cleanup or application-cache compliance from no-store?
Lessons connected to this case · 13
Return to the case with these lesson concepts. Connections do not add observations to the case record; they help examine its responsibilities together.