dom...@chromium.org, jbr...@chromium.org, liviu...@chromium.org
Enables prefetch to match even if URL query parameters change. The No-Vary-Search HTTP response header declares that some or all parts of a URL's query can be ignored for cache matching purposes. It can declare that the order of query parameter keys should not cause cache misses, that specific query parameters should not cause cache misses or that only certain known query parameters should cause cache misses. It could apply to multiple caches, but this entry refers to support for prefetch cache.
Gecko: No signal. Request for Standards Position: https://github.com/mozilla/standards-positions/issues/717.
WebKit: No signal. Informal positive signals from individual engineers at TPAC 2022. Request for Standards Position: https://github.com/WebKit/standards-positions/issues/106.
Web developers: Positive. Google Search is interested in experimenting with the header, specifically for the customizing server behavior use case.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No. This is a new opt-in feature.
Verify that the No-Vary-Search HTTP response header's design is useful and solves a real world problem.
Based on feedback, iterate on the design to increase functionality.
Validate the impact of this feature.
The No-Vary-Search header introduces a non-exact way to match the request URL with an already cached response. In theory this allows more possibilities to reuse responses in browser cache/s (if the browser implements this feature). If a browser does not implement the feature then it can simply ignore this HTTP response header and continue with an exact match between request URL and cached response. In implementing and defining the specification for this HTTP response header we made sure it follows RFC 8941 and also that it allows for extensibility in the future.
The prefetch version of this feature does not add any ongoing technical constraints, as the prefetch cache is small. It's possible a future version which also applies to the HTTP cache could have trickier interactions, due to the many entries in the user's HTTP cache requiring a different architecture. That is not under consideration for now.
The website owner can debug the feature in DevTools by making sure that, when navigating to a prefetched page by using a URL that matches under No-Vary-Search conditions, the navigation happens from the prefetch cache by looking at the Size column in the Network tab. In case of success, when hovering over the Size column in the Network tab of Dev Tools, they should see: "Served from prefetch cache, resource size: yyyB"
We are also working on a preloading panel (https://crbug.com/1361483) which shows all ongoing preloads, including both the targeted URL and the cached URL, if they differ due to No-Vary-Search.
Yes. WPTs will be landed before the experiment starts under external/wpt/speculation-rules/prefetch/no-vary-search folder.
Experiment to start in M110 and end in M115.
Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqYKutrvgMxR%3DnfAQOfBHNJo9ifrmFRSbiE0heDyeW0uKJA%40mail.gmail.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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqYLGT%2BV3_u_oumjHCZD05RRYY5guMjz1vb7501sNF1CANg%40mail.gmail.com.