- From: Koen Holtman <koen@win.tue.nl>
- Date: Mon, 30 Sep 1996 21:16:13 +0100 (MET)
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Larry Masinter: > [Koen:] >> While most of this discussion boils down to a question of taste, there >> *is* a real technical argument against stuffing `n/t' into the Accept >> header: saying `Vary: Accept, Accept-Language' in stead of `Vary: >> Negotiate, Accept-Language' will greatly reduce the efficiency of Vary >> header based caching. > >I'm really confused by something, but I'm having trouble working it >out. Let's suppose the Vary header in the response only notes the >request headers that the resource _actually_ varies on, whether or not >client does transparent negotiation. I'm going to use <negotiable> for >a bit to designate the indicator, since I don't like "n/t" much: [....] >So why do you need Vary: Negotiate at all? (suggestions on ><negotiable> later). Here is an example. Suppose I have variants in the languages `en' and `nl', and that I get Accept-Language: dk, *;q=0.5 from a user agent. Now, if the user agent is capable of transparent negotiation, I will send a list response (300 response), so that the user agent can choose the best variant itself (it may have more language preference information than it is sending). If the user agent cannot do transparent negotiation, I will send the `en' variant (my `en' variant has a link to the `nl' variant in it anyway). So in this case, just sending Vary: Accept-Language is not enough: the response also varies on the header which expresses if the user agent can negotiate. >Larry Koen.
Received on Monday, 30 September 1996 13:21:06 UTC