Resources · 99
Shared caching: test privacy, variants and invalidation
Speed up public responses while preventing cross-account reuse and checking how outdated versions are removed.
· 4 min
What this guide helps achieve
- Classify responses
- Inspect effective rules
- Test separation between users
- Exercise version correction
- Retain change controls
Quick check
- Does no-cache mean no storage?
- Does a cookie prevent shared caching?
- Is hit rate sufficient?
Step-by-step method
- 01
Classify responses
Inventory public pages, personalised responses, downloads and errors. For each class, record what may be retained, by which component and for how long. Identify responses varying by account, language or authorisation.
Deliverable: response and variation inventory.
- 02
Inspect effective rules
Inspect the response after the proxy, not only application configuration. no-cache requires revalidation before reuse; no-store prohibits storage. private restricts storage to private caches. Record CDN rules that can modify headers.
Deliverable: captured headers for each journey.
- 03
Test separation between users
With authorised test accounts, request the same URL under two identities and then without a session. Use distinct fictional markers. Check bodies, downloads and conditional responses. Repeat with cold and warm caches without including real personal data in evidence.
Deliverable: reproducible cross-account separation test.
- 04
Exercise version correction
Publish a test change, then check origin, proxy and browser. Measure time until the correct version appears and exercise the planned purge. For versioned assets, verify that HTML references the new filename or identifier.
Deliverable: propagation timeline and purge procedure.
- 05
Retain change controls
Replay scenarios after cache, sign-in or language changes. Track incorrect responses and removal capability alongside hit rate. Assign an owner for the control and urgent invalidation.
Deliverable: regression tests and named owner.
Decide where a response may be reused
Follow the actual returned content, then validate privacy and removal separately.
Personal response
Prevent cross-account reuse and inspect the received result.
Varying public response
Document necessary variations and compare the corresponding responses.
Corrected version
Exercise purge and check the new version across cache layers.
Illustrative case: a public catalogue may be shared while account details must remain separate. Cache speed does not validate that separation.
Four situations for exercising cache policy
Illustrative scenarios to replay with authorised test accounts and content. They are not customer incidents or measured performance results.
| Situation | Check to perform | Decision and expected evidence |
|---|---|---|
| Account page followed by the same URL without a session | Use two fictional identities and then an anonymous visit; compare content and headers after the proxy with cold and warm caches. | Any marker from another account blocks reuse; retain configuration and denial evidence without personal data. |
| Two languages at one address | Compare received variants and the language selection mechanism; check the actual cache key and Vary fields. | The variant must match the request; correct the key or separate addresses, then replay both visit orders. |
| Public document corrected at the origin | Check the version received from origin, shared cache and browser; record what the purge actually covers. | A CDN purge does not prove deletion of an already saved copy; document propagation and copies outside your control. |
| Conditional response after an identity change | Replay a request with a validator in a controlled environment and inspect the representation actually reused. | A 304 alone does not prove separation; examine the associated representation and permissions. |
Reusable worksheet
Complete with your authorised observations. These fields are a working template, not observed results.
| Field | Information to record |
|---|---|
| Response class | Public, personal, download or error |
| Variation | Account, language, authorisation and relevant parameters |
| Removal test | Change, cache layers, result and delay |
| Acceptance | Result by scenario, retained evidence and blocking discrepancy |
Worked example
Illustrative situation
Fictional example: an account page displays the marker ACCOUNT-A. A second identity and an anonymous visit then request the same URL after the cache has been populated.
Decision and expected evidence
If the marker appears elsewhere, stop shared reuse of that response, correct the rules and replay both visit orders. Also check the conditional response and retain evidence without personal data.
Distinguish the mechanisms
| Mechanism | Purpose | Check or limitation |
|---|---|---|
| Browser cache | Reuse by one user | Test sign-out and history separately |
| Shared cache | Reuse across users | Exclude personal responses |
| Versioned asset | Retain an identified version | Update references and preserve consistency |
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Separation | Cross-account scenarios without mixing | Block every discrepancy |
| Propagation | Observed delay until the correct version | Review rules and purge |
Common pitfalls
- Test sign-out and history separately
- Exclude personal responses
- Update references and preserve consistency
Frequently asked questions
Does no-cache mean no storage?
No. It requires validation before reuse. no-store concerns prohibiting storage. Check proxy rules as well.
Does a cookie prevent shared caching?
Do not assume it. Verify effective rules and responses using two test accounts.
Is hit rate sufficient?
No. A quickly reused response can be incorrect or personal. Check content, variants and invalidation.
Official references
References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.
Continue exploring
Related analysis
