W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: Summary of opinions on Negotiate header

From: Koen Holtman <koen@win.tue.nl>
Date: Mon, 30 Sep 1996 21:16:13 +0100 (MET)
Message-Id: <199609302016.VAA06469@wsooti04.win.tue.nl>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1666
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.


Received on Monday, 30 September 1996 13:21:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:20 UTC