Re: New Version Notification for draft-nottingham-variants-02.txt

> 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/ <https://mnot.github.io/I-D/variants/>
> 
> There is now a prototype implementation of the algorithms at:
>   https://github.com/mnot/variants-toy <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)..

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 :-).

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. 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?

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?


All in all though, I think this is an important step forward, to make the (ab)use of Vary less implementation specific.

Cheers,

— Leif