RE: Variant-ID proposal

>----------
>From: 	koen@win.tue.nl[SMTP:koen@win.tue.nl]
>Sent: 	Thursday, April 25, 1996 3:21 PM
>
>>Why not say that if there's a Vary:, there MUST be a variant-id?
>
>The main part of the discussion was about whether there should be a
>variant-id if there is no Vary but only Alternates.

Sorry, I missed that -- I think it was in a message prior to the one I
>responded to. 
>
>I do not like a MUST for inclusion of a variant-id.  Variant-ids make
>caches more efficient, but if you do not include them, this will not
>prevent caches from being correct.

OK.
>
>>>    - if a response from a varying resource does not include a
>>>      variant-id, the resource author may not assume that caching
>>>      services will be provided for the response.
>>
>>Don't fully uderstand this. If there's no Vary: header, and no
>>variant-id, then the cache will think its not a varying resource, and
>>will cache it as if it wasn't. If there is a Vary and no variant-id, I
>>don't know what it means
>
>The presence of a vary header implies that it is a varying resource.
>The presence of a variant-id means only that the origin server
>included one.
>
>> -- I'd be inclined to disallow servers from
>>sending it, and/or say that caches should not cache such responses. (Is
>>that what you meant?)
>
>Whay I mean is that if Vary is included but no variant-id is included,
>the resource author can expect the cache to work correctly, but cannot
>expect it to work efficiently.

OK.
>
>>>    - When using If-Invalid in requests on on varying resources, only
>>>      the Cval: header values of cached responses with variant-IDs can
>>>      be included
>>>    - Cache replacement (throwing old entity instances out of cache
>>>      memory because fresher ones that replace them are received)
>>>      happens using variant-ids, there is no talk about
>>>      Content-Location headers
>>
>>Does this mean that we delete Content-Location header from 1.1?
>
>I don't think so, it has some other uses.  Side issue: I don't like
>most of the current Location header text: it is over-specific about
>negotiation without there being any need for this.

Do you mean Location or Content-Location? There is no mention of content
negotiation in the Location header section.
>
>>>    - Plain 1.1 proxies are never allowed to add variant-IDs to cached
>>>      responses which do not have them, but caches operating under a
>>>      future content negotiation specification are allowed to
>>>      construct the same variant-ID the origin server uses when
>>>      constructing a 200 response out of separately cached components
>>>      on behalf of the origin server.
>>
>>Why say anything at all about this in the 1.1 spec?
>
>We don't need to say anything about this in the spec.  The above is
>only important in the context of the discussions we have been having.

That's what I thought -- I just wanted to make sure you meant that too.

Paul

Received on Friday, 26 April 1996 00:10:35 UTC