Contact emailsri...@chromium.org, kou...@chromium.org Explainerhttps://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. Blink componentInternals>Network>Cache <https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3ENetwork%3ECache%22> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/797 TAG review statusIssues 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. The main interoperability risk is that it gets widely adopted, and then other browsers implement something similar but different. That might leave us in the difficult situation of having to support two similar features, or doing a deprecation of a widely-adopted feature. *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 cachability 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 Goals for experimentation The feature will be enabled for 50% of Canary and Dev channels. The purpose of the experiment at this stage is to verify that performance and stability are not regressed by the feature being enabled. Ongoing technical constraints None Debuggability 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 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> ?No Flag name on about://flagsNone Finch feature nameHttpCacheNoVarySearch Requires code in //chrome?False Tracking bughttps://issues.chromium.org/issues/382394774 Launch bughttps://launch.corp.google.com/launch/4373880 MeasurementHistogram 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. Estimated milestones DevTrial on desktop 135 DevTrial on Android 135 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 Links to previous Intent discussionsIntent 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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdzO8VeeOZ72NeWui1dfhWMvYKO0gCsfHQAW0GBXH5mzJg%40mail.gmail.com.
