Re: Variant IDs

On Fri, 2 Feb 1996, Daniel DuBois wrote:

> 
> One thing I didn't understand from the phone conference was the fact that
> there seemed to be objections with variant IDs equaling cache-validator IDs?
> Is this true?

The objection is that a content-id remains constant but the validator
would change as the value of the resource changed.

> While I'm here I want to reemphasize (because we spent so much time talking
> about Vary: issues) that I believe URI: is the way to go for most content
> negotiation.  Additionally, if the URI: scheme is used, the whole point of
> the proxy server providing the origin server with a list of variantIDs is
> moot, because the proxy server doesn't have to provide such a list anymore.
> <BROKEN-RECORD>It can do its own computations, and know, by URL, which
> variant it wants, possibly completely saving a RTT with the origin server if
> that URL is in cache.  Vary: is strictly for the evil case that would
> otherwise be a "Cache-control: no-cache". </BROKEN-RECORD>

I start by confessing that I haven't studied the URI: header or
content negotiation in enough depth but it seems today that there
was a strong concern that a proxy/client might not know all 
possible variations of a resource. Hence, completion of the 
content negotiation algorithm wouldn't be possible at the proxy.

When for whatever reason the proxy concludded it couldn't be sure
it knew the answer, it needed to communicate to the origin server
(or a higher proxy in the hierarchy) a list of what it already
had cached. 

The content ID was also an abstraction which precluded direct
retrieval of a URL later and dealt with the situtation where 
there wasn't really a URL for the individual variations.

Dave Morris

Received on Saturday, 3 February 1996 07:28:15 UTC