No-Vary-Search HTTP header

[liviutinta]

Wotcher TAG!

I'm requesting a TAG review of No-Vary-Search. Chromium is currently experimenting only for the prefetch cache, so review from that point of view is most important, but we are designing this as a general primitive for more web platform caches, and engaging the HTTP community for how this could impact HTTP caches (both in the browser and in proxies and servers).

No-Vary-Search is a proposed HTTP header which changes how various URL-keyed caches match, by letting them ignore some or all query parameters, or query parameter order. For example, if the order of the query parameter keys should not cause cache misses, this is indicated using

No-Vary-Search: key-order

If the specific query parameters (e.g., ones indicating something for analytics) should not cause cache misses, this is indicated using

No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign")

And if the page instead wants to take an allowlist-based approach, where only certain known query parameters should cause cache misses, they can use

No-Vary-Search: params, except=("productId")

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md
• User research: None
• Security and Privacy self-review²: https://github.com/WICG/nav-speculation/blob/main/no-vary-search-security-privacy-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/nav-speculation
• Primary contacts (and their relationship to the specification):
  • Liviu Tinta (@liviutinta), Google, Chromium implementer
  • Domenic Denicola (@domenic), Google, specifier
• Organization/project driving the design: Google Chrome
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5071247189213184

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles

• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG

• The group where standardization of this work is intended to be done ("unknown" if not known): a mix of WHATWG (as part of the Fetch Standard) and IETF HTTPWG (for the header definition). Possibly some other WHATWG and W3C specifications will incorporate this for other web platform caches, e.g. HTML for the prerender cache, Service Workers for the service worker cache API, etc. Some discussion in https://wicg.github.io/nav-speculation/no-vary-search.html#status-and-venue.

• Existing major pieces of multi-stakeholder review or discussion of this design:

  • Presented and discussed at the W3C WebPerfWG at TPAC 2022: summary ("General positive reception")
  • Presented by @annevk to the 2022 HTTP Workshop: slides, discussion summary

• Major unresolved issues with or opposition to this design: none known at this point, but it's still somewhat early and this is a complex area.

• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[ylafon]

Hi, we reviewed this during our last f2f.

While it is not ideal to set expectations on other resources (varying by parameters, for example), we didn't see any major issue. We encourage you to continue experimenting with this and would like to see this work being discussed further in the IETF's HTTP-WG. Thanks,