RE: Variant-ID proposal

>----------
>From: 	koen@win.tue.nl[SMTP:koen@win.tue.nl]
>Subject: 	Re: Variant-ID proposal
>
>For example, after a request:
>
>GET /blah HTTP/1.1
>Accept-Language: en, nl
>
>you will get back, from a transparently negotiated resource, the
>response:
>
>HTTP/1.1 200 OK
>Content-Location: http://x.com/blah.en.html
>Alternates: { "http://x.com/blah.en.html" 1 {language "en"}}
>            { "http://x.com/blah.fr.html" 1 {language "fr"}}
>Date: ..
>Content-Language: en
>Cval: "3212419"
>...
>
>..English text about blah..
>
>IF you do a direct GET on http://x.com/blah.en.html, you will get the
>same English text entity, but a plain 1.1 cache does not have to know
>that.
>
>A plain 1.1 client will not know how to parse the Alternates header,
>and won't be able to interpret the Content-Location header, because
>the syntax of Alternates and the meaning of Content-Location will be
>defined later, in the content negotiation draft.  What the 1.1 client
>can do (according to the text I wrote for the 1.1 draft):
>
>- for answering requests on behalf of the origin server:
>  Alternates can be interpreted as Vary: {accept-headers}. So the
>  cache can store the response as a variant and return it for new
>  requests if request headers match in a certain way.
>
>- 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.)

Doesn't this have the consequence that if one of the alternates of
http://x.com/blah.html changes and gets a new CVal, say "131313", the
cache can't tell that it is an updated version of one of the existing
ones? So that both new and old will be in the cache until the old one
gets aged out?

Having the cache treat it as a variant with no variant-id makes it quite
different than normal variants, implementation-wise.  Why not assign a
variant ID? It can always be 1, because since there is a unique URI for
>the resource, there won't be more than 1 variant.

>
>- for cache replacement: The contents of the Content-Location header
>  can be used as a replacement key.  See the cache replacement text I
>  wrote for the 1.1 draft.
>
>I hope this clears up some of the confusion I generated with my
>previous reply.
>
>Koen.
>

Received on Thursday, 18 April 1996 17:10:06 UTC