- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 5 Mar 2018 14:27:32 +0900
- To: Leif Hedstrom <leif@ogre.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hey Leif, On 5 Mar 2018, at 1:30 pm, Leif Hedstrom <leif@ogre.com> wrote: > >> On Feb 12, 2018, at 7:47 PM, Mark Nottingham <mnot@mnot.net> wrote: >> >> Hello everyone, >> >> FYI, a fairly substantially updated Variants. Pretty version at: >> https://mnot.github.io/I-D/variants/ >> >> There is now a prototype implementation of the algorithms at: >> https://github.com/mnot/variants-toy >> ... which resulted in many of the changes. >> >> Negotiation for format (Accept) is now also supported. > > > I’m generally very much in favor of this over the Key specification. For starters, this is a *lot* easier to implement I think. But even more important, it solves the issue of knowing when not to request for a variant when we know from a previous response that it’s not available. For example, this makes it possible to efficiently solve the problem of caching (and serving) plain-text, gzip and brotli compressed content (without a “negative” cache).. Thanks, that's helpful feedback. > > A couple of thoughts: > > Section 3: I find it somewhat confusing that the example shows a response with Variant-Key: gzip, fr, for a non-gzip response. I understand why (to satisfy subsequent request for a gzip’ed french variant), but it might be useful to explain this? It is sort of explained both before, and after this, but I still found it confusing :-). I know; I'll try to make this clearer. > Section 4: We’ve had this discussion before (with Key), but i still feel that it’s unfortunate and more complicated that the rules are that the “freshest” variant header rules. It’d be easier for at least some implementations if the variant header had the same life-time as oldest (first) cached response header. It encourages using the latest header, but doesn't absolutely require it; """ Select one member of stored-responses and let its "Variants" header field-value(s) be variants-header. This SHOULD be the most recent response, but MAY be from an older one as long as it is still fresh. """ If we have a number of implementations emerge that this is a problem for, I'm comfortable relaxing it as necessary. > For example, the current proposal could in theory require some implementations to update previously cached responses (I think). I understand there’s a MAY here on the actual evaluation, but 4 step 4 seems to imply that you must check the most recently cached header? Which text are you referring to here? > It’s also not clear to me why the stored-responses have to be sorted by Date? Why not let the cache serve the first cached response it encounters that can satisfy the request, regardless of Date? Well, there's a general preference in HTTP for fresher responses; this tries to honour that. However, given the latitude that caches are given in selecting from the resulting list, if this makes implementation difficult, I think I'm OK removing it. Cheers and thanks again, > > > All in all though, I think this is an important step forward, to make the (ab)use of Vary less implementation specific. > > Cheers, > > — Leif > -- Mark Nottingham https://www.mnot.net/
Received on Monday, 5 March 2018 05:28:17 UTC