Re: Rethinking content negotiation (Was: rethinking caching)

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.