Summary

  • The active No-Vary-Search draft lets supporting caches ignore specified query differences when matching responses. It does not replace freshness, authorisation or content negotiation, and it does not certify that client-side decisions are equivalent.
  • Chrome documents a specific activation boundary: a prerendered page initially sees its prerendered URL, then receives the final URL when an equivalent navigation activates it. Query-dependent state must be bound or updated at that handoff; changing the address bar is not proof that an old data model or action target changed with it.

Imagine a catalogue whose initial HTML is the same for two products. The product identifier in the query determines what the application fetches and displays later. A browser prepares the common page before the reader clicks. During prerendering, application code reads the first identifier and holds it in a model. The reader then chooses the second product through a URL considered equivalent for response reuse. The prepared document becomes visible, and its address changes to the selected URL.

Has the application's decision changed too?

The question is not whether the two initial HTML responses match. They may genuinely be interchangeable. It is whether the product data, visible selection, analytics attribution and any eventual action target now agree with the reader's actual navigation. A captured variable does not become current merely because the browser updates its location. This is an analytical scenario, not a reported browser defect or customer incident.

No-Vary-Search makes the distinction operationally important. The header permits a narrower kind of equivalence than applications may casually infer from it. It can establish that a query difference need not force a new server response. It cannot establish that every decision made before the final navigation remains appropriate afterwards.

A response contract, not an identity merger

draft-ietf-httpbis-no-vary-search-09 is the current active HTTPBIS Working Group Internet-Draft at this research cutoff. Its August 2026 text expires on 18 February 2027. Datatracker shows the document submitted for publication and in “Approved-announcement to be sent::AD Followup”, with Proposed Standard as its intended RFC status. It has advanced through approval processing; it is not presented here as an unapproved individual suggestion. Nor is it yet presented as a published RFC. The analysis uses the versioned draft rather than guessing the content of a future publication.

The proposed field is a Structured Fields Dictionary. Its params list names query parameters whose differences can be ignored; its except list takes the opposite approach, retaining the named parameters as significant and ignoring the others. Those entries cannot coexist. key-order addresses whether the ordering of parameter names matters. Invalid recognised forms fall back to the default variation configuration rather than silently granting ignore-all behaviour.

These details describe comparison, not a universal instruction to discard query information. The origin supplies the field. Intermediaries must not insert, remove or change it unless acting as the origin for the response. A cache needs to implement the extension before its additional matching rules have effect. The header's appearance does not prove that every browser, CDN or forward proxy supports it.

Other conditions remain. RFC 9111's cacheability and freshness rules still apply, as do content negotiation and Vary. A cached response that matches under No-Vary-Search is not thereby authorised for a different user or eligible for indefinite reuse. The equivalence is a claim about which query differences do not semantically change the served response, within the rest of the HTTP caching contract.

For a common HTML shell, a product identifier might genuinely be unnecessary to produce that shell. For a personalised response or a server-rendered product page, the same identifier may be essential. The field name cannot decide which application architecture is in use. That judgement belongs to the origin and requires evidence about the actual response, not the label attached to a parameter.

Prerendering creates a handoff that prefetching does not

Chrome's official documentation makes the lifecycle explicit. No-Vary-Search is supported for navigation speculation involving prefetch and prerender. During prerendering, the page initially observes the URL used to prepare it. If the eventual clicked URL differs only in covered search parameters, Chrome can reuse the prepared page and replace its URL with the final one on activation.

The documentation cautions that JavaScript depending on search parameters should run after activation. Client-rendered content may need to be updated then. Its example separates an identical initial product-page HTML response from the product-specific data eventually rendered by JavaScript. This is a concrete documented Chrome behaviour, not a claim about every browser's current support.

Prefetching and prerendering should therefore not be merged into one mental model. Fetching a response in advance is not the same as preparing a page that can execute code before it becomes the active page. The stale captured-state problem described here concerns the latter lifecycle. Ordinary navigation, prefetch reuse and prerender activation need distinct test populations, even where they share the same header.

An expectation such as expects_no_vary_search in speculation rules is also not an editorial stamp of correctness. It helps preparation where a response header is expected. The actual origin contract still matters, and neither the hint nor a successful speculative download proves that the application handles the final query properly.

The required handoff is conceptually small. Treat pre-activation state as preparation. At activation, identify the final selected parameters, bind the relevant application state to them, and update every dependent projection. A refreshed heading with an old action target is not a complete transition. A new data fetch with attribution still tied to the speculative URL is another incomplete transition. The application should know which state is provisional and which has been reconciled with the active navigation.

The difficult cases are not solved by reading the URL once

Testing only a clean first load misses the boundary. The useful scenario prepares one permissible query and activates another, then inspects both presentation and the decisions that follow from it. Does the selected record agree with the final URL? Does a user-initiated action refer to that record? Are query-dependent measurements recorded against the active visit rather than a merely anticipated one?

These questions do not imply that all work must wait. A reusable shell, common assets and genuinely query-independent preparation can still be valuable. The distinction is between doing work early and treating an early guess as the reader's settled choice. A system can prepare alternatives without committing the identity of the eventual action before activation.

Nor should activation be mistaken for general permission. It identifies which navigation actually became active. Consent, authentication and authority for a consequential action remain separate requirements. Rebinding an identifier correctly is necessary for many decisions; it does not authorise every decision about that identifier. A reader can arrive on a page without instructing it to disclose information or perform an external operation.

The draft's security section places a firm limit on the server side too. An origin must not declare a parameter insignificant where doing so would bypass processing required for safe reuse. Its examples include authorisation, user identification, signature verification, consent, routing, auditing and revocation. An activation routine cannot repair an HTML response that was never safe to share or whose required server processing was bypassed.

That limit matters for shared caches. Incorrectly ignoring a parameter that selects sensitive or user-specific content can expose a response intended for one user to another. Client-side lifecycle discipline and server-response equivalence are complementary controls. Neither is a substitute for the other, and a fast transition cannot be evidence that both were satisfied.

Equivalence has parsing and release boundaries

The proposal interprets queries through application/x-www-form-urlencoded parsing, using WHATWG conventions. It is not an invitation to remove substrings from URLs. The default configuration compares the query exactly; a non-default configuration introduces parsing, filtering and, where specified, stable ordering by key before comparing pairs.

Encoding and repeated values deserve negative tests. Plus signs and percent encoding can affect the parsed values. Ignoring the order of parameter names does not permit arbitrary reordering of values attached to the same name. No Unicode normalisation is performed. The draft also identifies lossy decoding of invalid percent-encoded UTF-8 as a source of false positives. Applications should not make security distinctions depend on invalid sequences remaining distinct after comparison.

There is a future-decision boundary as well as an activation boundary. A parameter irrelevant to today's shell might acquire meaning in a later release. An except policy that preserves only a few named parameters also ignores unfamiliar future ones. A narrow params policy leaves unlisted parameters significant. Neither approach is universally correct, but they assign different responsibilities to application evolution.

The governance response is to review equivalence whenever parameter meaning, server output or client activation behaviour changes. Bind the claim to a release and an accountable owner. Test the old stored response against the new navigation semantics, not just the new header against a new response. These are author recommendations, not additional fields required by the draft.

A newly emitted policy does not retrospectively rewrite every cached object. The draft uses the stored response's variation configuration for matching and permits strategies that prefer newer, conflicting policy information. It does not promise instant withdrawal of old equivalence everywhere. Likewise, it does not change invalidation requirements: invalidating conceptually equivalent URIs is permitted but not required. A state-changing request need not invalidate every representation the application regards as equivalent.

Query-string cache busting is consequently not a universal escape hatch. If the changing parameter is ignored by the relevant stored policy, changing it may fail to obtain a new response. A transition needs appropriate validation, invalidation or a distinct resource namespace rather than an untested assumption that a new query always forces fresh work. The method chosen depends on the cache and deployment; it needs testing against old responses that remain eligible for reuse, not just a newly emitted policy.

Put the local decision where the final choice exists

The heng.lu account of minimum initial specification and localised future decision offers a useful discipline here. A small contract should identify what can be safely shared and where a later decision remains local. It need not centralise every product selection or forbid useful speculative work. But it must not erase the point at which the application learns the actual future choice.

No-Vary-Search's server-response claim can remain narrow. The browser's documented activation handoff can remain explicit. The application can then make its query-dependent decisions with the final navigation available, rather than letting an optimisation settle them implicitly beforehand. Voluntary adoption works better when these boundaries are stated than when all layers inherit a vague promise of “the same page”.

Even privacy benefits need that precision. The draft explains that private-cache reuse can avoid some origin processing of tracking identifiers. Shared caches still receive incoming requests containing them, and the field does not disable client-side tracking. Reuse is not anonymity, just as activation is not consent. The durable benefit is a smaller, testable promise: prepare the equivalent response early, then bind the reader's decision when the reader's choice becomes real.

Sources

  1. Datatracker: current No-Vary-Search document and publication state.
  2. No-Vary-Search revision history.
  3. Archived revision 09, including comparison, caching and security.
  4. Revision 09 plain text.
  5. Revision 09 structured source.
  6. HTTP Working Group extension text.
  7. HTTP extensions discussion tracker.
  8. HTTPBIS Working Group.
  9. RFC 9110: HTTP semantics.
  10. RFC 9111: HTTP caching.
  11. RFC 9651: Structured Field Values for HTTP.
  12. RFC 6943: identifier comparison and security.
  13. WHATWG URL Standard.
  14. WHATWG Infra Standard.
  15. Chrome: prerendering and No-Vary-Search activation cautions.
  16. heng.lu: minimum specification, local future decision and voluntary adoption.
  17. heng.lu: The Policy Mirror.