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 >> >> *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.
