- From: Daniel DuBois <ddubois@rafiki.spyglass.com>
- Date: Thu, 21 Dec 1995 15:24:01 -0600
- To: David Robinson <drtr1@cus.cam.ac.uk>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
At 05:39 PM 12/21/95 GMT, David Robinson wrote: >>for the specified vary quanity for comparison purposes. This is a huge >>burden on a proxy because it doesn't just have to save headers once, it has >>to save headers for each request that doesn't have the exact same paramters >>as previous requests. > >Firstly, I'm not convinced that it's a _huge_ burden; does anyone have >any statistics on Accept: headers? It's likely not much of a burden now, but as browsers become more willing to let uses set their own q's, or add type and encoding helper-apps to their Accept* headers, it will become hugely burdensome. >Yes, there are cases where a Vary: header will not provide enough information >for a cache. But are you arguing against the implementation of the >Vary: header? Yes. >resources. You seem to be arguing that it may not be enough for caching >of content-negotatiated resources. Does that matter? Yes. Caching is integral. >I'm not quite sure what you mean, but half of the point of the Vary: header >was to inform about the server's varying content outside the content >negotiation scheme. So, tell me again what functionailty the Vary: header would provide? How would I modify my behavior based on a Vary: header? Either variances are acceptable future responses (in the content provider's mind), and hence cachable, or their not, and then the server will send a Cache-Control. ----- Dan DuBois, Software Animal http://www.spyglass.com/~ddubois/ I absolutely do not speak for Spyglass.
Received on Thursday, 21 December 1995 13:29:36 UTC