Re: Problem with q values in Accept-Language

My mistake on the 1, sorry.

While the spec doesn't attach any meaning to the ordering, real-life
programs do. Accept-Language values "en fr" and "fr en" give very different
results. Eg for Apache " When you specify a language preference in your Web
browser, it uses the designated language in a HTTP header it sends to the
Web server whenever a request is made; this header is Accept_Language and
will typically be the list of language keywords the user specifies (in
descending order of preference), so our Web browser will be
sendingAccept-Language: fr de en"

Saying that the weights and/or ordering is entirely up to the server doesn't
give any guidance for clients or servers. Is the expectation that my
browser, for example, would set up some kind of negotiation with every
different server it hits in order to determine what the meanings of the
weights ought to be? Or that each server should simply guess at what the
values from the client mean? Or is the only thing the server can surmise, in
the absence of negotiation, that smaller weights (no matter what the
magnitude) mean lesser preference (eg that "en, fr;q=0.99999" is equivalent
to "en, fr;q=0.00001"?

Mark

On Tue, May 6, 2008 at 7:51 PM, Brian Smith <brian@briansmith.org> wrote:

> Mark Davis wrote:
>
> > The specs do not distinguish between at least two different possible
> > reasonable interpretations of what the q values of c, e, and g are:
> >
> >  1. c;q=1.0, e;q=1.0, g;q=1   // always 1
> >  2. c;q=0.7, e;q=0.5, g;q=0.9 // always same as previous
> >
>
> The specification states explicitly that the quality value defaults to
> "q=1". Only interpretation #1 is correct. The specification does not assign
> any significance to the ordering of the alternatives in the Accept headers,
> and there is no implicit relationship between the parameters of one choice
> and the parameters of another choice.




 of the numbers really is. My native tongue is English, I can understand
> > Swiss German and German, my French is rusty, and Italian basic. Which of
> > these should I use?
> >
> >  1. en;q=1, gsw;q=0.9,  de;q=0.9,  fr;q=0.8,  it;q=0.7
> >  2. en;q=1, gsw;q=0.5,  de;q=0.4,  fr;q=0.3,  it;q=0.2
> >  3. en;q=1, gsw;q=0.99, de;q=0.95, fr;q=0.03, it;q=0.02
> >
> > All are descending order, but depending on what algorithm the consumer
> > of
> > the tags uses, they could have far different results. Without being able
> > to
> > have any consistent expectations for what the q numbers mean, producers
> > of
> > tags don't know what settings to provide or what difference it will
> > make,
> > and consumers of tags don't know what the producers meant, in order to
> > meet
> > any expectations.
> >
> 2. And even once that ambiguity is cleared up, nobody knows what the
> meaning
>
> This is server-side content-negotiation, not client-side
> content-negotiation. The client will not be able to predict what the server
> will respond with. The requirements for the Vary header require the server
> to respond consistently with its previous responses for that resource
> (except for Vary: *), but there is no consistency required between servers
> or resources.
>
> If the client application needs precise control over variant selection,
> then it should use some kind of client-side content negotiation, where the
> server lists relevant choices and the client picks a specific one.
>
> Regards,
> Brian
>



-- 
Mark