Summary

  • No-Vary-Search allows an origin to say that selected query keys, or their order, do not change a response for cache matching. A supporting cache may reuse accordingly, but ordinary freshness, Vary, authorization and validation rules still apply.
  • The field changes neither the requested URL nor the flow of identifiers through browsers, CDNs and logs. The consequential act is the origin's classification: false equivalence can become stale state, cache poisoning or cross-user disclosure.

A browser requests /catalog?item=42&utm_source=mail. A cached response exists for /catalog?utm_source=search&item=42. The visible URLs differ. The application may know that the campaign label never changes the catalogue body and that the order of the two keys is irrelevant. An ordinary HTTP cache cannot safely infer either fact from the strings alone.

No-Vary-Search is an attempt to transmit that narrow semantic knowledge. In revision draft-ietf-httpbis-no-vary-search-09, dated 17 August 2026, an origin can attach a Structured Fields dictionary to a response and describe how its query should be compared with later requests. As of 29 August, the document is an active HTTPBIS Internet-Draft, intended for the Standards Track and approved pending an announcement with Area Director follow-up. It is not yet an RFC. The IANA HTTP Field Name Registry does not yet contain the field.

That status matters. Operators can test the protocol, but they should not cite a future RFC number or treat the current grammar as immovable. The draft's value is a precise proposal and review record, not proof that a given cache supports it correctly.

The baseline is exact for a reason

RFC 9111 permits a cache to satisfy a request with a stored response only after several conditions hold. The method must be reusable, the target URI must match, fields named by Vary must match, the stored response must be fresh or successfully validated, and applicable response and request controls must allow reuse. Different query components normally mean different target URIs.

That conservative separation prevents a cache from guessing application meaning. ?account=alice and ?account=bob are just bytes at the HTTP layer until the origin says more. A popularity pattern, matching body samples or a key called tracking is not authority to collapse them.

The draft modifies only the target-URI matching step. It does not cancel Vary, make a stale response fresh, remove authentication, widen a cache-control permission or certify that a representation is public. If two requests become equivalent under the field, every remaining RFC 9111 condition must still pass.

A small dictionary carries a large claim

The field is a Dictionary under RFC 9651. Three keys define the current shared language. key-order is Boolean. params is an inner list of query-key strings that may be ignored. except reverses the selection: only its listed keys continue to vary. params and except cannot coexist.

For example, an origin might declare that utm_source and utm_campaign do not vary the response while key order is insignificant. It has not told the cache to erase those parameters or rewritten the canonical address. It has made a claim about response equivalence for one matching decision.

The origin is the authorised declarant because it owns the application semantics. An intermediary must not insert, delete or modify the field unless it is acting as the origin for that response. A CDN rule invented from observed traffic would reverse this allocation: the layer least able to know why a parameter exists would acquire the power to merge it.

The parser fails closed. A missing, malformed or contradictory value produces the default configuration: the whole query and its order continue to matter. This can cost cache hits, but it does not deliberately reduce separation. Unknown dictionary keys are ignored. Future extensions are allowed only to expand equivalence; a future restriction needs another field, because an older recipient that ignores an unknown key must not reuse too broadly.

Equivalence has hard walls and surprising corners

Comparison never crosses scheme, host, port or path. The path /a cannot become equivalent to /b, and no declaration on one origin authorises reuse from another. Within that boundary, a non-default policy parses the query using the WHATWG application/x-www-form-urlencoded model, removes ignored pairs or keeps only the except set, optionally sorts by key, and compares key-value pairs. Duplicate keys remain; values still matter.

This is more than textual deletion. Percent escapes are decoded, plus signs become spaces, empty segments are handled by the form algorithm and invalid UTF-8 may become the replacement character U+FFFD. Two distinct invalid byte strings can therefore collapse onto the same decoded key. Conversely, the algorithm performs no Unicode normalization, so canonically equivalent NFC and NFD spellings remain different.

These edges are not trivia. A signature verifier may operate on original bytes while the cache compares decoded pairs. A routing layer may distinguish duplicate order. A consent system may attach meaning to an empty value. The draft says the field is unsuitable where the query does not follow the form-urlencoded model. The only safe classification is one tested against the application's actual parser and every downstream consumer.

RFC 6943 gives the broader warning: identifier comparison fails when different parties normalize, scope or interpret identifiers differently. Here the failure is executable. A false positive can select a stored body before the origin gets another chance to disagree.

The cache keeps the final reuse decision

A conforming cache may perform the broader comparison; it is not compelled to. It may try an exact key first, index a simplified key derived from the most recent known policy, or decline a modulo-policy hit. Voluntary adoption preserves a useful boundary: origin knowledge becomes an option available to the participant that bears the reuse consequence, not a command to spend or expose data.

Policies can change. If stored responses for the same authority and path carry conflicting non-empty configurations, the draft permits a cache to prefer the one associated with a more recent Date value. That is a convergence hint, not a proof of semantic truth. A bad new declaration can be newer than a good old one; clock and cache topology complicate the observation.

The draft also leaves HTTP invalidation intact. After an unsafe method changes state, a cache may invalidate responses that are equivalent under the field, but it is not required to broaden invalidation that way. Two entries treated as equivalent for retrieval can therefore survive differently after mutation. Query-string cache busting can likewise stop working when the changed key is declared irrelevant. A content-addressed path remains a different and usually more legible deployment mechanism.

Tracking was not removed

The second request still contains its full URL. A browser displays it and can store it in history. A CDN or forward proxy receives it. Access logs, analytics and downstream services may record it. No-Vary-Search changes cache matching; it is not a privacy scrubber, a redirect or a canonicalization instruction.

A private browser cache might spare the origin from processing a later tracking parameter because it answers locally. A shared cache still sees the identifier, and the declaration can enlarge the set of requests eligible to receive one stored response. Calling the field “tracking removal” would hide both facts.

The security line is categorical. A key must not be ignored when it influences authorization, identity, signatures, consent, routing, auditing, revocation or any processing needed for safe reuse. This includes innocuous-looking flags whose meaning exists outside the response body. A billing attribution parameter can be semantically irrelevant to pixels yet essential to an obligation. A one-time signature may produce the same asset yet control who may fetch it.

In a private cache, a mistake harms one context. In a shared cache, it may send Alice a body fetched for Bob. private, correct cache keys and response controls still matter, but they do not excuse a false declaration. The origin owns classification; the cache owns separation at the moment of reuse. Authority follows consequence at both points.

Evidence must follow the request that did not reach the origin

The standards record can establish the grammar, intended algorithm and declared safety rules. It cannot prove that an origin's catalogue key is decorative, that a CDN implemented revision -09, that a hit occurred, or that no user boundary was crossed.

An operational record needs the visible requested URL, the stored response's URL and field, the parsed configuration, the simplified comparison input, the selected entry, all ordinary RFC 9111 checks, user and cache partition context, hit or miss, origin bypass and delivered body fingerprint. Without that chain, a high hit ratio cannot distinguish correct equivalence from successful leakage.

Lu Heng's minimum initial specification provides the right constitutional reading. The common layer is deliberately small: a dictionary and comparison process. The application retains the future decision about semantic keys; each cache retains voluntary adoption. His account of running-code primacy then moves proof from configuration to observed execution. The header says what should be possible. A matched request and delivered representation record the executed outcome.

The data-sovereignty distinction is equally useful. Formal control of an origin setting does not mean practical custody of the data path. The browser may show one identifier, the CDN may log it, the cache may return a body fetched under another query, and the origin may never see the second request. Governance must map those separate powers instead of assigning the whole transaction to the field's issuer.

The decisive safety property is negative: when parsing, classification or implementation is uncertain, exact matching remains available. More misses are reversible. A cross-user response is not.