Re: Variant IDs

>] >How does the cache know if the two "foo.txt" are variants of one
>] >another, or if the one-and-only "foo.txt" has changed?
>]
>] The presence of a "Vary:" header, ie:
>] HTTP/1.0 200 OK
>] Content-ID: "xxxxx"
>] Vary: Foo-Header
>
>header in the response.  So you're right.  However, the Vary: header 
>value is a _request_ header name.

Right -- telling a proxy/client that a resource varied on a response header
would be pointless, because the proxy/client would have to re(HEAD?)request
the object every time to see what the response header would be, to know if
this request varied.  Whereas, if we Vary: on a request header, the
advantage is that a proxy could make attempts to store old headers and
preemptively serve from its cache w/o any validation request to the origin
server.

>How do I match it up the Accept-* 
>values in the Vary header with the Content-* entity headers in the 
>response?

Define "I" in this sentence.  You, the response-receiving proxy don't match
the Accept-* headers with the Content-* headers.  The idea of the Vary:
header is that the server has gone off and done something you shouldn't be
trying to make inferences about.  It's negotiating opaquely, and the best
the proxy can hope to do is to do equality matches on subsequent request
headers.  Anything except exact equality on the Vary:ed request headers
necessitates the origin server performing its proprietary negotiation
algorithm locally.

>I suppose I've saved the Accept-* headers in the request, so 
>maybe that is what I use to see if there is already another instance in 
>the cache.  But can't I have two different Accept-* configurations 
>translate to the same entity?

Sure you can.  You are describing the flaws with the Vary: system.  Even
though different request headers may map to the same variant, the Vary:
header doesn't give enough information for proxies/client to make inferences
about the origin server's negot. algorithm, the origin server's variants, or
the choice an origin server would make on an individual request.  When an
origin server is using the straight-out-of-the-book content negotiation
algorithm in the HTTP spec, using the URI/Alternates proposal is much better
for everyone involved, especially the users, who can then pick the variant
they want directly and bypass us protocol writers.

>gotchas -- having the origin-server just _tell_ the cache that it's 
>variant number 23 would be a lot easier, and it saves transmitting the 
>entity-body when you've already got it cached, even though it's got 
>different Accept-* header values.

I certainly agree that it's important to know which variant you are dealing
with.  But I think Roy is arguing that a URL/Content-ID pair is effectively
equal to a Variant-ID for sensing 'equality of variant' which is the only
necessary variant operation that should be done outside the origin server.
Additionally, an over-dependence on a Variant-ID construct leads to a bunch
of questions of what happens when the list of variants changes.  If each
variant only differs by Content-ID, then those questions are answered for
the inductive case.

>Whereas, if there is a variant ID, you know what validator to overwrite.

Assuming a static list of variants that always map to the same VariantID's.
A Content-ID system wouldn't have that additional maintenance requirement
placed on the server.

>In this sense Vary and Content-ID are orthogonal. A really stupid cache 
>could not use Vary and just go back to the origin-server to do all 
>content negotitation, and still get the advantage of caching for all 
>entity-bodies.

Your description of a stupid cache is true for either a Variant-ID or a
Content-ID system.  This is what you mean when you say "Vary and Content-ID
are orthogonal" right?

-----
Dan DuBois, Software Animal           http://www.spyglass.com/~ddubois/
    Download a totally free copy of the Spyglass Web Server today!
        http://www.spyglass.com/products/server_download.html

Received on Tuesday, 12 March 1996 09:08:16 UTC