W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1995

Re: Rethinking content negotiation (Was: rethinking caching)

From: Daniel DuBois <ddubois@rafiki.spyglass.com>
Date: Thu, 21 Dec 1995 15:24:01 -0600
Message-Id: <9512212124.AA07913@rafiki.spyglass.com>
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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:57 UTC