Re: #428 Accept-Language ordering for identical qvalues

On 17 January 2013 09:14, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2013-01-17 09:59, Roy T. Fielding wrote:
>> than there are servers that implement language negotiation and
>> actually want to resolve ties at random.
>
> They do not "want" to resolve at random; they do so because they have
> implemented what the spec says. There's no reason to create an ordered list
> structure when the spec says that an unordered list is sufficient.

I think no implication of randomness should be permitted by the specifications.
They should instead require that a deterministic process be used, and
that, other than requests to services which explicitly exist to
provide random results (e.g. Wikipedia's "Random Page" link), the same
request should generate the same result providing nothing pertinent to
the resource has changed on the server.

Someone, I don't recall who, gave the example of a home page loading
blog posts via AJAX, where the blog posts are available in two
languages. Random selection between the variants, where (q * qs)
values are equal for both languages, or are being ignored, would
result in a mixture of languages being presented in the resultant web
page, and a reload of the page would generate a different mixture. I
agree that such behaviour is undesirable in all cases I can think of,
(excepting the case of a 'randomizer' service URI) and should be
discouraged or better, prohibited in the spec text.

I believe Apache uses file size in it's TCN mechanism to resolve equal
(q*qs) results. It then falls back to a non-exhaustive ordered list in
it's config in the highly unlikely case that two static files varying
by language have the same byte length. Apache seems to try, therefore,
to be wholly deterministic. (Roy may know whether this is accurate for
A-L in Apache.)

At it's most basal extreme, the deterministic process could be an
ASCII value comparison of the language tags' bytes using strcmp()
implemented by the httpd software.

This should apply to all Accept-* headers.

-- 
Nicholas.

Received on Tuesday, 22 January 2013 13:41:11 UTC