A resource can have multiple representations and cache identities

A resource is the conceptual target identified by a request; a representation conveys its current or intended state in a particular form. Content-Type identifies the representation's media type, while Content-Encoding describes a coding applied to its representation data, such as gzip. These are different from transfer framing. A JSON representation compressed with gzip is still JSON after decoding. Charset rules depend on the media type rather than an assumption that every byte sequence is text. Clients should verify the response's actual metadata instead of treating their own Accept request as proof of what arrived.

Proactive negotiation can consider request fields such as Accept, Accept-Language, and Accept-Encoding along with the server's available representations and selection policy. Quality values express relative client preferences within their defined matching rules; q=0 excludes the matching item under those rules. They are not measured probabilities or global utility scores that can be multiplied indiscriminately across every field. Server availability and policy still matter, and unspecified preferences have specification-defined behavior. A useful example must state its available variants and tie-breaking assumptions rather than claim that one abbreviated header determines every possible server's choice.

A Vary response field identifies request fields that influenced representation selection so caches can match subsequent requests appropriately. If Accept-Language selects the content, a cache must not assume every request for the URL can reuse the stored language variant. Matching follows field-specific equivalence and the cache's rules, not necessarily raw byte-for-byte header string equality. Vary: * indicates that a cache cannot determine suitability from ordinary matching alone and requires origin participation under the specification. A proxy must not generate that wildcard. Selection metadata belongs with the stored response and its validator.

Vary is not an access-control mechanism. A response influenced by user identity may need private storage restrictions, no-store, or other explicit shared-cache permissions depending on its contract; adding a user-related field to Vary is not a universal safe-public-caching recipe. Avoid leaking personalized data through an incomplete key or an overbroad reuse rule. Conversely, adding unnecessary high-cardinality selection fields can fragment the cache and reduce useful reuse. Optimize only after preserving correct selection and isolation: serving the wrong user's or wrong language's bytes quickly is still a failed request.

A representation rollout can change validators, compression, content length, and decoding cost even when the conceptual resource stays the same. Test both old and new clients, selected variants, absent preference fields, unacceptable choices, and shared-cache reuse paths. A strong validator must meet its identity requirements for the representation being validated; do not carry a byte-identity claim across transformed bytes without checking those rules. Record response media type, content coding, Vary dimensions, cache outcome, and user-visible decoding errors so a hit-rate improvement does not conceal mismatched content or newly expensive decompression.

The cache lab models variant-identity pressure only as a toy address cycle. Reset, explicitly set BOTH C=4 and s=4, predict twelve hits among N=16 initial requests, then Play or Step. Reset and re-set BOTH C=4 and s=2; predict zero hits because eight distinct addresses cycle through four slots. Edits retain time and recompute the deterministic trace from empty; each comparison needs Reset. The addresses are illustrative identities, not actual Accept values, and the lab has no Vary or freshness logic. Use it to explain capacity pressure from more identities without treating fewer variants as permission to select incorrectly.