Awesome to see this about to ship! On Mon, Sep 29, 2025 at 2:55 PM Mike Taylor <[email protected]> wrote:
> 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 >>> >>> *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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af56ff90-8782-43e9-8f40-152357d0118a%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/CACuR13ekS%3D37Ew3zm3JRJiaGFV7ioQTeq6Xh7t6%3D-mK7ZhTP6A%40mail.gmail.com.
