A supplier may serve English and Chinese from one public endpoint using Accept-Language. If the cache key ignores that choice, one visitor can receive another language’s response. This is a representation-selection contract, separately from whether personalised pages may be stored.
Primary evidence and claim boundaries
The Vary response header identifies request fields that influence a response for caching. A cache must support and apply the relevant variation; a header alone does not prove a CDN’s configuration. Primary reference · Read 18 October 2026.
Filled acceptance example
Original synthetic teaching scenario, not a client case, provider integration test or business result. The example policy needs the actual owner’s approval; scroll the table on narrow screens.
| Input and state | Declared check | Expected output and decision |
|---|---|---|
| GET/public-help; resolved locale=en | Key includes path+resolved locale | English stored under /public-help|en |
| Same path; resolved locale=zh | Key includes same dimensions | Chinese stored separately at/public-help|zh |
| Both responses use key/public-help | Bodies have different approved language | Collision: reject the cache contract |
| No supported language match | Declared fallback=en | Record fallback and matching key; do not invent a third locale |
Practical handover procedure
- Decide whether URLs or negotiated request fields select language. For negotiated responses, document normalisation and fallback so equivalent headers do not create uncontrolled variants.
- Prime the same endpoint in EN then ZH and reverse the sequence in an authorised test cache. Compare actual body language, response policy and repeat-visit bytes.
- Record the cache product and supported key dimensions. Treat missing configuration evidence as unknown, especially when an intermediary overrides origin headers.
Interpret the outcome
The first two rows cannot share a stored representation. The failure is visible even if every response returns200. The example uses normalised language tokens, not a recommendation to cache an unbounded raw header or to change established language URLs.
Acceptance decision
Require correct language in both warm-up orders and a proven supported cache key. Preserve the approved privacy policy independently.
Limits and unverified work
Synthetic public endpoint and cache identities; no cache purge, CDN change, private-data test or alteration of existing language routes.
Download the filled bilingual acceptance record — Contains the inputs, steps, expectations and limits. This is a teaching record, not an executable production integration.