- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 19 Jul 2018 13:39:54 -0400
- To: Yoav Weiss <yoav@yoav.ws>
- Cc: Ilya Grigorik <igrigorik@google.com>, Jeffrey Yasskin <jyasskin@google.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
On 16 Jul 2018, at 5:49 am, Yoav Weiss <yoav@yoav.ws> wrote: > >> >> That said, the syntax of Variant-Key now allows a response to match multiple keys, which at least helps in the duplication issue; see the last part of: >> >> https://httpwg.org/http-extensions/draft-ietf-httpbis-variants.html#variant-key >> > >> > I agree that's better, but still, the response for `DPR: 2, Viewport: 300`, `DPR:1, Viewport: 600` and `DPR: 2, Viewport: 600, Save-Data: on` could be one and the same. Avoiding that cache duplication can be an important factor. >> >> Right, but that response would have on it something like: >> >> Variants: DPR;1;2, Viewport;600;1200, Save-Data;on;off >> Variant-Key: 1;2, 600, on;off >> >> If that's not expressive enough, maybe we should be talking about a Variant-Key syntax that lets you specify alternative sets of values, e.g., >> >> Variants: DPR;1;2, Viewport;300;600, Save-Data;on;off >> Variant-Key: 2;300;off, 1;600;off, 2;600;on >> > I like the expressiveness that second syntax enables. > > Just to clarify: when processing the keys, we're not relying on ordering, but on the values declared as potential variants, right? Here, within each variant-key value (separated by ","), the parameters (separated by ";") need to be ordered in the same way that Variants are. So in the first key above, "2" refers to DPR, "300" refers to Viewport, and "off" refers to Save-Data. In the meeting, we also mentioned that the ordering of the variant-key values themselves was important; the first one indicates *this* response's key (to allow simpler implementations to ignore the other keys). What do you mean by "the values declared as potential variants"? > If so, I can see cases where the variants values may have collisions (e.g. if `Save-Data` were defined as "0" and "1" values, it would collide with DPR). At the same time, I'm not sure this will be a problem in practice, and we can probably avoid it becoming a problem by being careful about future client hint values and their interactions with existing ones. -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 19 July 2018 17:40:19 UTC