W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: #428 Accept-Language ordering for identical qvalues

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 18 Jan 2013 11:57:55 +0100
Message-ID: <50F92AB3.6040408@gmx.de>
To: Amos Jeffries <squid3@treenet.co.nz>
CC: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, ietf-http-wg@w3.org
On 2013-01-18 11:49, Amos Jeffries wrote:
> On 18/01/2013 11:13 p.m., Julian Reschke wrote:
>> On 2013-01-18 10:57, "Martin J. Dürst" wrote:
>>> On 2013/01/18 18:07, Julian Reschke wrote:
>>>> If the client sends
>>>> Accept-Language: en, de
>>>> and the server returns German text, although English would have been
>>>> available, is it still compliant?
>>> One way to claim compliance is to claim that the German text is of
>>> higher quality. If there are no (or the same) q-values, then higher
>>> quality on the server side wins.
>> Let's assume for this argument that they are same quality.
>>> So I'm with Roy (and now Amos) on this.
>> I don't see how that follows from what you just said...
>> Best regards, Julian
> The server has potentially some idea of the translated % or quality of
> trust in each phrases translation.
> Even putting that aside though:
> Server A responds with German. Server B responds with German.
> Which one was selecting randomly? which was responding with sequential
> search and missing English? you can't tell.
> Likewise, if they return German and English respectively you still can't
> tell unless you are maintaining state and considering requests statefully.
> Then you need to consider a server which does object translation based
> on the Accept-Language header. If it *were* to respond with random
> selection of language between those two and host an entire site
> translated into both. Users would end up getting a random language
> change on every page load as they navigated, potentially each of several
> components on a page in different languages. The random selection is
> *not* a good algorithm to use from this point of view and effecitively
> mandates stateful sessions just for the translation to work in a
> user-friendly way.

Um, no. That would be the case if common browsers indeed would send 
multiple values without qvalues, which they do not.

> FWIW: Squid is able to do language negotiation on its generated
> responses fast and statelessly only by ignoring q-values and handling
> the list as ordered. Managing q-values or comparing the entire list
> against available languages increases the response processing costs by a
> factor of 6.

That may be true but doesn't change the arguments. We are not designing 
something new. If Squid is ignoring qvalues then it's not compliant to 
RFC 2068, RFC 2616, *nor* the new text.

Best regards, Julian
Received on Friday, 18 January 2013 10:58:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC