- From: Daniel DuBois <ddubois@rafiki.spyglass.com>
- Date: Tue, 12 Mar 1996 11:04:02 -0600
- To: Paul Leach <paulle@microsoft.com>, fielding@avron.ICS.UCI.EDU
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>] >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