Intent to Ship: No-Vary-Search support for the HTTP disk cache

[Adam Rice]

Contact emails

ri...@chromium.org, kou...@chromium.org

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

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?

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.