- From: Jeremy Roman <jbroman@chromium.org>
- Date: Tue, 18 Jun 2024 17:31:29 -0400
- To: Rory Hewitt <rory.hewitt@gmail.com>
- Cc: ietf-http-wg@w3.org
- Message-ID: <CACuR13fENsddR_-3NK+w8w5OvcOwnyt=_eiHsK0E0S2X4rr=ZQ@mail.gmail.com>
On Tue, Jun 18, 2024 at 4:42 PM Rory Hewitt <rory.hewitt@gmail.com> wrote: > Hi Jeremy, > > In the two examples sections, can you provide an example of a URL and show > how specifying this header will change caching - your examples give some > "Input => Result" answers in a table, but I think an actual sample URL > (e.g. https://www.example.com?you=cool&me=notcool) showing the effect of > various header values affect how the content should be cached would be > useful. > Very reasonable to point out that examples that better explain this could be added. To give some inline here for now: *Cases where the server ignores order, but the client pages may not consistently order keys.* No-Vary-Search: key-order https://example.com/products?color=red&size=medium https://example.com/products?size=medium&color=red *Cases where a server has parameters which affect processing but not the response (at least, semantically). For example, it might prioritize the request, route it to different backend instances, or mark it with a label for debugging.* No-Vary-Search: params=("processing_priority") https://example.com/search?q=vancouver&processing_priority=userblocking https://example.com/search?q=vancouver&processing_priority=background *Cases where there are parameters which are only processed by client-side script (e.g., to initialize client state)* No-Vary-Search: params=("zoom") https://example.com/map?q=vancouver&zoom=5 https://example.com/map?q=vancouver&zoom=9 *Cases where there are parameters which are not yet known when loading (esp. preloading) happens, but which can be processed client-side* No-Vary-Search: params=("via") https://example.com/search?q=vancouver&via=homepage_banner https://example.com/search?q=vancouver&via=destinations_sidebar On Tue, Jun 18, 2024 at 1:20 PM Rory Hewitt <rory.hewitt@gmail.com> wrote: > >> Hey Jeremy, >> >> > This was originally No-Vary-Query, but the web-exposed APIs call this >> part of the URL "search", so this change was requested in a W3C discussion. >> >> I can understand why you changed the name from "No-Vary-Query", but given >> that it's primarily a mechanism to change the way that content is cached, I >> think it makes sense to call it "No-Vary-Cache" >> >> I think this document needs a high-level overview section, explaining >> what you're trying to do and what specific problems you're trying to solve. >> You're clearly deep in the weeds on it (I don't mean that pejoratively!) >> but for those of us that are coming at it fresh, it needs something there >> to tell us about the idea/project. >> > I'll avoid getting too deep into bikeshed painting, but briefly: I hoped to evoke the longstanding Vary header <https://www.rfc-editor.org/rfc/rfc9110#field.vary>. > On Tue, Feb 20, 2024 at 6:14 PM Jeremy Roman <jbroman@chromium.org> wrote: >> >>> Hello HTTPWG: >>> >>> This is tangentially unrelated to my previous email, but I've split it >>> into another thread to avoid entangling the two. >>> >>> A developer previously reported to us that their ability to use the >>> prefetch cache was limited because their prefetch request URLs needed to >>> include certain query parameters which are different from the navigation >>> request URL, even though these URLs do not affect the resource the server >>> ultimately produces (and therefore, the client can safely use the >>> resource). The explainer >>> <https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md> we >>> wrote goes through some of the possible use cases in more detail. >>> >>> The semantics we have right now (and the header name, No-Vary-Search¹) >>> are designed with the concept of being implementable in non-browser HTTP >>> implementations, but since browser use cases were what we are focused on, >>> there are some places where the semantics rely on, e.g., WHATWG URL >>> <https://url.spec.whatwg.org/>, which may vary in subtle ways from >>> other concepts of the meaning of the query string (since IETF HTTP doesn't >>> currently take a position on that as far as I know). >>> >>> The specification draft >>> <https://wicg.github.io/nav-speculation/no-vary-search.html> is >>> currently hosted by the W3C's Web Incubator Community Group (WICG) and >>> we've previously discussed it in a W3C context, but it was suggested that >>> we bring it to HTTPWG's attention, too, and if there is interest among >>> participants it could migrate to an HTTPWG RFC instead of continuing >>> incubation in the web standards venues. >>> >>> ¹ This was originally No-Vary-Query, but the web-exposed APIs call this >>> part of the URL "search", so this change was requested in a W3C discussion. >>> >>
Received on Tuesday, 18 June 2024 21:31:47 UTC