Cache-key & privacy mismatch

Claim labels used in this report

1 · URI first: query values normally select different targets

Normative RFC 9111 §2 defines the minimum cache key as the request method plus target URI. RFC 9110 §7.1 says the target URI excludes only a fragment; path and optional query identify the target resource. Under that minimum model, /item?value=alpha and /item?value=beta are distinct targets and do not select one another’s stored response.

That is not a promise about application meaning or every deployed key. A cache, routing layer, framework, or CDN may normalize, remove, sort, decode, or otherwise treat query parameters specially. HTTP leaves those extra choices to implementation and configuration. If tenant=A changes the representation but an intermediary strips tenant, the whole path has a cache-key/privacy defect even though exact target-URI matching would have separated the original URIs.

2 · Vary narrows matching; it does not authorize sharing

RFC 9110 §12.5.5 identifies the request fields that might have influenced selection; RFC 9111 §4.1 requires the nominated values from the original and presented requests to match before a stored response is used without revalidation. Vary does not grant storage permission: no-store, private, or the authenticated-request rule can independently stop storage/reuse. Current MDN likewise recommends private for personalized content instead of trying to protect it with a cookie in Vary, and recommends consistent Vary values on 200/default/304 responses.

3 · Cookie and Authorization are separate privacy cases

4 · Adversarial cache-key / privacy worksheet

Read every row as stored response → presented request. “Match” means a candidate may be selected; it does not mean the entry is fresh, permitted to be reused, or safe to share. — means absent.

5 · Expected protocol outcomes versus local model output

Expected protocol outcomes The worksheet above is the normative decision aid: exact query targets differ; nominated Vary fields must match; Cookie is not automatically a key; Set-Cookie alone is not a cache barrier; and Authorization needs explicit shared-reuse permission. These expectations do not force a browser, proxy, CDN, framework, or service worker to behave identically.

Interpretation limit: a model hit proves only that this model did not call its synthetic origin function. It cannot prove storage, reuse, validation, forwarding, origin contact, or absence of leakage anywhere else.

6 · A safe pre-deploy adversarial check

1. Make an authorized controlled origin emit a redacted marker such as X-Variant-Marker: A, B, lang-en, or anon. Never place a real token or personal data in the marker.
2. Warm the intended shared hop with variant A. Then use a fresh client for the same target with variant B. Repeat with two query values, two Accept-Language values, Cookie absent/A/B, and Authorization absent/A/B. Keep redirects, host, port, and POP fixed; record cold/warm state.
3. At the same hop, capture status and Cache-Control, Vary, Set-Cookie, Age, Cache-Status, Via, and the redacted marker. Marker A on B is a fail even if headers look cacheable. A Cache-Status hit is positive evidence only for the named cache that inserted it.
4. Treat absent Age or Cache-Status as unknown, not “no cache.” RFC 9111 says lack of Age does not imply that the origin was contacted; RFC 9211 makes Cache-Status optional/configurable.
5. If the response is personalized, fix the storage audience first (private, no-cache or no-store as appropriate), then address missing Vary or URI-key inputs. Do not “fix” a user-specific body with public or by assuming Vary: Cookie is a confidentiality control.

URL='https://authorized.example.test/profile'
# Warm with a synthetic test identity A; do not use a production token.
curl -sS -D /tmp/a.headers -o /tmp/a.body \
  -H 'Cookie: sid=<synthetic-A>' "$URL"
# Present a different synthetic identity B to the same target.
curl -sS -D /tmp/b.headers -o /tmp/b.body \
  -H 'Cookie: sid=<synthetic-B>' "$URL"
# Inspect the same-hop evidence without printing credential values.
grep -iE '^(HTTP/|cache-control:|vary:|set-cookie:|age:|cache-status:|via:|x-variant-marker:)' \
  /tmp/a.headers /tmp/b.headers

Sources and evidence limits

RFC links are primary normative sources; MDN links are current developer-facing cross-checks. All source pages below were retrieved or cross-checked on 16 Sep 2026 UTC. No vendor documentation was needed.

• RFC 9111 §2 · minimum cache key
• RFC 9111 §3 · storing responses
• RFC 9111 §3.5 · authenticated requests
• RFC 9111 §4 · constructing responses
• RFC 9111 §4.1 · Vary matching
• RFC 9111 §5.2 · Cache-Control
• RFC 9111 §7.3 · sensitive information / Set-Cookie
• RFC 9110 §7.1 · target resource
• RFC 9110 §7.6.3 · Via
• RFC 9110 §11.6.2 · Authorization
• RFC 9110 §12.5.5 · Vary
• RFC 6265 · HTTP State Management
• RFC 9211 §2 · Cache-Status
• MDN · HTTP caching
• MDN · Cache-Control
• MDN · Vary
• MDN · Cookie
• MDN · Set-Cookie
• MDN · Authorization

• The RFC minimum key is not a prescription for a browser, service-worker Cache API, reverse proxy, CDN, framework, or vendor’s extra key. Query normalization, host/authority handling, partitioning, cookie handling, request coalescing, and POP selection remain deployment-specific.
• This run did not measure a real shared cache. The local model cannot establish that a production layer stores, reuses, validates, forwards, or strips the same response.
• Vary compares nominated request fields; it cannot describe arbitrary server state, network address, TLS/session context, or application logic not represented in the message. Vary: * is a coarse “cannot know without origin” signal.
• Vary: Cookie compares a complete field value, not a parsed identity. Ordering, duplicate names, irrelevant cookies, partitioning, and application parsing can create cardinality or correctness problems; this report does not prescribe universal canonicalization.
• Explicit Authorization permission is a protocol gate, not an authorization model or confidentiality guarantee. Whether a representation is safe to share remains an application/deployment judgment.
• A 200/304, Age, Cache-Status, Via, browser DevTools row, or origin counter identifies only the layer that emitted or recorded it. Absent Age/Cache-Status is not evidence that no cache exists.
• Cookie processing by user agents, including whether a browser exposes Set-Cookie to script, is distinct from intermediary storage/reuse. This report does not test browser cookie-jar behavior.

← HTTP caching basics and report index · Dated baseline · ETag versus Last-Modified · Research history →