LGTM3
On 9/29/25 11:31 a.m., 'Dan Clark' via blink-dev wrote:
LGTM2
On Monday, September 29, 2025 at 11:26:49 AM UTC-7
[email protected] wrote:
LGTM1; love to see this sort of performance-improving change that
also improves standards conformance.
On Friday, September 26, 2025 at 1:29:44 AM UTC-7 Adam Rice wrote:
*Contact emails*
[email protected], [email protected]
*Explainer*
https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md
*Specification*
https://httpwg.org/http-extensions/draft-ietf-httpbis-no-vary-search.html
*Design docs*
https://docs.google.com/document/d/1RS3q6qZ7-k9CvZsDYseGOXzcdQ9fGZ6YYnaW7fTPu7A/edit
*Summary*
Enables the HTTP disk cache to use the No-Vary-Search response
header to share a cache entry between URLs that differ only in
the query parameters. Developers can use No-Vary-Search to
specify query parameters that have no impact on the user
experience. A common example might be an id used to track
conversions. Supporting this header in the HTTP disk cache
means that if the user later goes back to that same page
without the conversion id, it can be used or revalidated from
the cache rather than having to be fetched from scratch from
the network. Previously, No-Vary-Search support shipped for
the navigation prefetch cache, prefetch and prerender
speculation rules, and prerender. This launch makes it
generally available to any feature that uses the HTTP disk cache.
*Blink component*
Internals>Network>Cache
<https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3ENetwork%3ECache%22>
*Web Feature ID*
Missing feature
*TAG review*
https://github.com/w3ctag/design-reviews/issues/797
*TAG review status*
Issues addressed
*Risks*
*Interoperability and Compatibility*
No-Vary-Search is a best-effort feature, meaning that servers
cannot rely on it being implemented by caches. As a result, it
is quite easy to remove if not widely adopted.
/Gecko/:
Positive (https://github.com/mozilla/standards-positions/issues/717)
/WebKit/: No
signal (https://github.com/WebKit/standards-positions/issues/106)
/Web developers/:
Positive (https://techshed.runbookdocs.com/docs/tips/6/no-vary-search)
/Other signals/:
*Ergonomics*
This feature will usually be used in tandem with the
Cache-Control, Last-Modified and/or ETag response headers that
control the cacheability of the response. The implementation
design was carefully chosen to avoid additional disk accesses
and to minimize the overhead when it is not in use. To avoid
context switches, it must run synchronously on the IO thread
in the network service, so high performance is essential.
*Activation*
Implementation is easy for developers who are able to
customize their HTTP response headers. The most time-consuming
part is determining which query parameters do not affect
user-visible behavior. Developers who cannot customize their
HTTP response headers will have to wait for support from the
framework or hosting providers they are using.
*Security*
The feature must not expose any information to the page that
it would not have had otherwise. For this reason, the
implementation uses exactly the same partitioning method as
the HTTP disk cache. An overly-broad setting for the
No-Vary-Search response header can, in combination with other
server-side bugs, lead to an attacker being able to control
the content which is shown to the user. However, the risk is
no worse than with existing features that permit customizing
responses like ServiceWorkers. See the design document for
more details.
*WebView application risks*
Does this intent deprecate or change behavior of existing
APIs, such that it has potentially high risk for Android
WebView-based applications? None.
*Debuggability*
Beyond the usual display of headers in the Network section,
integration with DevTools is not currently planned, but may be
added as a future enhancement.
*Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?*
Yes The feature is implemented in //net, so all platforms that
use the //net layer for navigation & subresources will have it.
*Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
Yes
https://wpt.fyi/results/fetch/http-cache/no-vary-search.tentative.any.html?label=experimental&label=master&aligned
<https://wpt.fyi/results/fetch/http-cache/no-vary-search.tentative.any.html?label=experimental&label=master&aligned>
*Flag name on about://flags*
None
*Finch feature name*
HttpCacheNoVarySearch
*Rollout plan*
(RARE) Ships disabled, then flips on for all users
The feature behaves like a progressive enhancement, in that it
improves cache hit rate when enabled and used, but everything
still works without it. As there are a number of other
features blocked on this one, it is useful to launch in M141
rather than wait for M142.
*Requires code in //chrome?*
False
*Tracking bug*
https://issues.chromium.org/issues/382394774
*Launch bug*
https://launch.corp.google.com/launch/4373880
*Measurement*
Histogram HttpCache.NoVarySearch.UseResult collects
information about what proportion of requests use a different
cache entry due to No-Vary-Search. Histogram
HttpCache.NoVarySearch.HeaderParseResult collects information
about what proportion of response have a No-Vary-Search
header. It is also tracked by HTML & JavaScript usage metrics
at
https://chromestatus.com/metrics/feature/timeline/popularity/4425
(currently
around 1.5% of page loads).
*Availability expectation*
Feature is available on Web Platform Baseline within 24 months
of launch in Chrome.
*Adoption expectation*
Feature is considered a best practice for some use case within
12 months of reaching Web Platform baseline. Feature is used
by specific partner(s) to improve performance within 3 months
of launch in Chrome.
*Adoption plan*
Internal experiments are already ongoing to use the feature.
DevRel will evangelise the performance benefits once the
experiment results are available.
*Non-OSS dependencies*
Does the feature depend on any code or APIs outside the
Chromium open source repository and its open-source
dependencies to function? None.
*Estimated milestones*
Shipping on desktop 141
DevTrial on desktop 135
Shipping on Android 142
DevTrial on Android 135
Shipping on WebView 142
*Anticipated spec changes*
Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links
to known github issues in the project for the feature
specification) whose resolution may introduce web
compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way). None; everything in
https://github.com/httpwg/http-extensions/labels/no-vary-search is
editorial
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5808599110254592?gate=6604429773766656
*Links to previous Intent discussions*
Intent to Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67ac01fe.2b0a0220.1b0c0.02a6.GAE%40google.com
This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/055cab4c-b26b-4b16-9624-4d43e04a7090n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/055cab4c-b26b-4b16-9624-4d43e04a7090n%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af56ff90-8782-43e9-8f40-152357d0118a%40chromium.org.
