Re: Variant-ID proposal

Paul Leach:
>>From:  koen@win.tue.nl[SMTP:koen@win.tue.nl]
>>Subject:       Re: Variant-ID proposal
[...]
>>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?

No, the old one will be thrown out, but this is the job of cache
replacement, not cache refreshing.  Cache refreshing only makes an
expired version (entity instance) fresh again (if it can).

See below for cache replacement: there the Content-Location header
does indeed need to be used.

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

Koen.

Received on Thursday, 18 April 1996 22:47:33 UTC