Re: Variant-ID proposal

    > - for cache refreshing: the contents of the Cval header (in this case
    >   "3212419" can be put in the If-Invalid header sent to
    >   the origin server.  A typical if-Invalid header sent, if 3 variants
    >   are caches, would be
    >      If-Invalid: "3212419", "453232", "756456"
    >   (Note that the origin server must ensure that all opaque validators
    >   for the three variants are indeed different, because there is no
    >   variant-id attached to disambiguate them.)
    
    No, it can't do that.  It needs to either include a variant-id of
    some kind or not use this mechanism at all.  That is, as I recall,
    why I started with variant-id being a MUST even for transparently
    negotiated URIs.  There is absolutely no difference between having
    an origin server ensure that all opaque validators are unique across
    variants, and having an origin server always include a variant-id;
    in fact, the latter is much simpler.

I basically agree with Roy that I cannot think of a good reason
why an origin server would not be able to generate variant-IDs,
but I also agree with Koen that it's possible to make the protocol
work without variant-IDs, albeit somewhat less efficiently.

At any rate, I was able to write a set of cache-key rules that seems
to work for both approaches, and they aren't too complex.  Although
they may have subtle bugs.  Stay tuned.

-Jeff

Received on Friday, 19 April 1996 01:38:50 UTC