- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 11 Jul 2018 13:57:43 +1000
- To: Leif Hedstrom <leif@ogre.com>
- Cc: Yoav Weiss <yoav@yoav.ws>, Ilya Grigorik <igrigorik@google.com>, Jeffrey Yasskin <jyasskin@google.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
> On 11 Jul 2018, at 2:31 am, Leif Hedstrom <leif@ogre.com> wrote: > >> 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 > > This seems rather convoluted, almost aching to the complexity of the old “Key” draft. And now instead of having one secondary cache key, I might have 3 (or <n>) that I must look up? I agree that deduping in the cache is admirable, but perhaps that is an implementation detail for the caches or services? I'm not sure that's the right characterisation; it lets you register this response for three different keys; i.e., you don't have to look for three different things on each request, you just have to do one lookup and find the appropriate key (which might be any of these three). Also, note that the form at the top (in the first example) is already in the spec; are you pushing back on that? It also has the capability to assign multiple keys to a single response, just in a more limited way. Personally, I like the second form; it seems like a good balance between complexity and the capabilities that people have been repeatedly asking for here. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 11 July 2018 03:58:15 UTC