--- title: "The Same AI Resource URL Can Select Different Cached Representations" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/http-vary-request-fields-cache-representation-selection" last-updated: "2026-10-21" --- # The Same AI Resource URL Can Select Different Cached Representations Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. An HTTP cache uses the request fields named by a stored response's Vary header to distinguish representations at the same URL. For direct reuse without revalidation, those fields must match the original request. A fresh English model card therefore need not satisfy a request for its French representation. ## Read Vary as response-selection information RFC 9110, section 12.5.5, identifies Vary as information about request fields that might have influenced selection, beyond method and target URI. Vary: Accept-Language names a request field; it does not label the response's language. Accept-Language expresses language preferences. The origin selects the representation. A model card in English and French can therefore remain one resource with two representations. References: [RFC9110](https://www.rfc-editor.org/rfc/rfc9110.html#section-12.5.5) ## Hold freshness constant in a public model-card example Consider the fictional public GET URI /ai/model-card. A supplier is being asked to deliver the model card in the language required by a public documentation workflow. The cache contains two stored responses. Record E contains an English model card and was stored from a request with Accept-Language: en. Record F contains a French model card and was stored from a request with Accept-Language: fr. Both responses contain Vary: Accept-Language. Stipulate that both entries are fresh and all other ordinary conditions for direct reuse are satisfied. There are no credentials, private responses or cache extensions in this example. No origin revalidation occurs in the comparisons below. These are hypothetical records, not observed cache results. ## Compare en, fr and an absent field Applying RFC 9111, section 4.1, a subsequent request with Accept-Language: en matches E; Accept-Language: fr matches F. A request without that field matches neither. After permitted normalization, an absent nominated field matches only another absence. If a third response with Vary: Accept-Language had been stored from a request without Accept-Language, that absence could match; it would not turn E or F into matches. References: [RFC9111](https://www.rfc-editor.org/rfc/rfc9111.html#section-4.1) ## Distinguish a semantic match from Vary: * RFC 9111 permits field-aware normalization that preserves specified semantics; matching need not mean byte-identical header text. Vary: * always fails matching. RFC 9110 explains why: the recipient cannot determine later suitability without origin involvement. This is not a general prohibition on storing that response. References: [RFC9111](https://www.rfc-editor.org/rfc/rfc9111.html#section-4.1), [RFC9110](https://www.rfc-editor.org/rfc/rfc9110.html#section-12.5.5) ## Keep matching alongside the other reuse conditions RFC 9111, section 4, makes request matching one of several reuse conditions. Passing it creates neither freshness nor successful validation. Vary also supplies neither authorization nor private-response isolation. The example establishes only representation matching for public requests. References: [RFC9111](https://www.rfc-editor.org/rfc/rfc9111.html#section-4.1) ## Connect the supplied request to the representation you need Start with the required deliverable: the French model card for the public documentation workflow. The supplied request should express the selection inputs that the origin uses for that deliverable. Then connect the stored response to the original request that produced it. For the stipulated fr request, a URI-only offer that returns E has failed the representation requirement even though E is fresh. The supplier's explanation needs to connect the fr request to F; unchanged URLs and entry ages cannot answer that question. Conversely, suppose the workflow needs French but the supplied request says en. Selecting E can be correct HTTP matching while still missing the workflow's need. Clarify that request-to-deliverable discrepancy with the application team. A matching comparison does not prove that the right preference was supplied. For the absent-field request, neither the default language nor the workflow's intent has been supplied by this example. Establish those separately. Also assess model-card and translation accuracy on their own evidence. ## Use the related guides for different reuse decisions The prompt-cache guide addresses whether an AI system reuses prefix computation or a previously generated answer. The S3 ETag guide addresses object and checksum evidence. Neither decision establishes which of E or F can answer this HTTP request. Use the related articles when the supplier's claim concerns computation reuse or dataset byte integrity. ## Scope any surrounding physical deployment separately If the wider AI project also needs equipment installation, the related Complete Physical Deployment service and project inquiry concern agreed physical work. Share a nonconfidential equipment outline and physical handoff needs. HTTP cache behavior remains with the appointed software team. References: [L1](https://www.leviathansystems.co/services/turnkey-gpu-deployment) ## Primary sources - [RFC9110 — RFC 9110: HTTP Semantics, June 2022](https://www.rfc-editor.org/rfc/rfc9110.html#section-12.5.5). Checked 2026-10-20. Sections 12.5.4–12.5.5 explain language preferences and representation selection. - [RFC9111 — RFC 9111: HTTP Caching, June 2022](https://www.rfc-editor.org/rfc/rfc9111.html#section-4.1). Checked 2026-10-20. Sections 3–4.2 distinguish storage, request matching and other reuse conditions. - [L1 — Leviathan Systems: Complete Physical Deployment](https://www.leviathansystems.co/services/turnkey-gpu-deployment). Checked 2026-10-20. Agreed equipment installation and physical handoff define the separate project inquiry. ## Related Leviathan resources - [Prompt computation or a reused answer: what does an AI cache hit reuse?](/articles/ai-prompt-prefix-cache-versus-semantic-answer-cache) - [S3 ETags and checksums: compare dataset byte-integrity evidence](/articles/ai-dataset-s3-etag-versus-checksum-integrity) - [Complete Physical Deployment](/services/turnkey-gpu-deployment) - [Discuss the surrounding equipment installation and physical handoff](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Fhttp-vary-request-fields-cache-representation-selection) - [The Same Convolution Weights Can Produce Different Boundary Features](/articles/ai-convolution-padding-boundary-feature-values) ## Discuss the surrounding physical deployment Share a nonconfidential equipment outline, proposed locations and physical handoff needs to discuss installation scope and availability. [Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/http-vary-request-fields-cache-representation-selection)