- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 14 Jul 2018 12:52:07 -0400
- 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 11:56 am, Leif Hedstrom <leif@ogre.com> wrote: > > > >> On Jul 10, 2018, at 9:57 PM, Mark Nottingham <mnot@mnot.net> wrote: >> >> >> >>> 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). > > > Assuming the request only satisfies one of those secondary cache keys, right? Is it possible / allowed that a request could match multiple of these Variant-Keys? Well, sort of. Currently, the cache uses the variants header compute a list of candidate keys, sorted in order of preference. Those candidates are then matched with the keys in Variant-Keys. The cache is encouraged to choose the most preferred key, but isn't required to. > And what if a response comes back with 10,000 secondary keys. We let it do that? I'm sure we can put some sane limits on it, and a cache isn't required to support that many in any case. > What if they overlap with other objects primary cache key? Is that an issue? I'm not sure what you mean here; can you give an example? >> 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. > > No, not pushing back on anything. Just concerned that we’re making things more complex, and potentially expensive on the server. :-). > >> >> 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. >> > > Fair enough. I see that there’s a session in Montreal covering this topic, maybe that’s a good time for clarifications? Yep. -- Mark Nottingham https://www.mnot.net/
Received on Saturday, 14 July 2018 16:52:32 UTC