Re: source quality, caching, and Vary:

I feel like there's at least a 50% chance I'm being totally stupid, but 
maybe someone will be kind enough to explain the following example and 
it'll unconfuse me:

Suppose //www.myhost.com/page.html has two variants: Content-Language: 
fr and Content-Language: en.

Suppose I made a request to my friendy proxy-cache
	GET //www.myhost.com/page.html HTTP/1.1
	Accept-Language: en;q=1,fr;q=.5

and got back the english version, and it had a vary header
	Vary: Content-Language
which it cached along with page.htm.

Now, someone makes a request to the same cache:
	GET //www.myhost.com/page.html HTTP/1.1
	Accept-Language: en

Can I serve it from the cache?  I think the answer is NO. Because I 
didn't tell you that the qs for "fr" is 1.0 and the qs for "en" is 
0.001, so what the origin server would return is the French version!

Even with more reasonable values for the qs of the French and english 
versions, I wouldn't be able to serve this request from the cache:
	GET //www.myhost.com/page.html HTTP/1.1
	Accept-Language: en;q=1;fr;q=.6
because the qs multiplied by the higher q for "fr" could make it be the 
choice in this case.

I think that I can serve up a cached page if every Accept* header in 
the request has the same choices in the same order with the same or 
lower q values for all but the first choice, which must have an equal 
or greater q value. This assumes that the origin server is using the 
content negotiation algorithm in section 12 of the 1.1 spec, or (I'm 
not certain,  but I suspect so) _any_ "linear" algorithm that could 
involve other "qs"-like parameters that are unknown to the proxy-cache.

Based on these examples, am I correctly understanding how Vary: is 
supposed to work?

If so, then I think that for completeness the Vary: proposal  needs to 
specify what "semantically identical" means for each of the header 
values that can vary, because for at least some of them, it isn't 
trivial, as I hope the above example shows.

Paul
----------
] From: Daniel DuBois  <ddubois@rafiki.spyglass.com>
] To: Paul Leach;  <http-caching@pa.dec.com>
] Subject: Re: source quality, caching, and Vary:
] Date: Monday, February 12, 1996 4:58PM
]
] At 01:44 PM 2/12/96 PST, Paul Leach wrote:
] >I don't understand how Vary: works where there are different levels of
] >source quality. It would be nice if the source quality of a resource
] >were returned someplace when using Vary: instead of URI:.  Or did I
] >miss something obvious?
]
] There is no source quality with Vary.  Or rather, if there was a source
] quality, it's transmittal would be internal to the server and useless to the
] receiver.  The idea of Vary: is that it is appropriate only when the server
] is unwilling to give both the full details of the variants, and/or unwilling
] to use the standard content negotiaion algorithm.  The source quality is
] only useful if the standard q*ql*qc*qe*qs algorithm is used.  If a origin
] server uses a home-grown algorithm (like if HTTP_USER_AGENT == "Spyglass
] Mosaic" then foo else bar) the whole q*ql*qc*qe*qs thing goes out the
] window, and hence, qs with it.
] -----
] 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, 13 February 1996 00:14:18 UTC