This problem has been report as Debian bug
http://bugs.debian.org/288615

From: Vincent Untz <vincent@vuntz.net>
Subject: Issue with language negotiation exceptions

Looking at http://httpd.apache.org/docs-2.0/content-negotiation.html, I
can read this:

=======
The server will also attempt to match language-subsets when no other
match can be found. For example, if a client requests documents with the
language en-GB for British English, the server is not normally allowed
by the HTTP/1.1 standard to match that against a document that is marked
as simply en. (Note that it is almost surely a configuration error to
include en-GB and not en in the Accept-Language header, since it is very
unlikely that a reader understands British English, but doesn't
understand English in general. Unfortunately, many current clients have
default configurations that resemble this.) However, if no other
language match is possible and the server is about to return a "No
Acceptable Variants" error or fallback to the LanguagePriority, the
server will ignore the subset specification and match en-GB  against en
documents. Implicitly, Apache will add the parent language to the
client's acceptable language list with a very low quality value. But
note that if the client requests "en-GB; q=0.9, fr; q=0.8", and the
server has documents designated "en" and "fr", then the "fr" document
will be returned. This is necessary to maintain compliance with the
HTTP/1.1 specification and to work effectively with properly configured
clients.
=======

This looks good except it seems there's a small issue when Apache adds
the parent languages. I have a client that requests: "fr-fr,en-us;q=0.3"
and the server is configured like this:
AddLanguage fr .fr
AddLanguage en .en
LanguagePriority en fr

So, apache is adding the parent languages to the client request because
the server is not configured to deal with fr-fr and en-us.
However, the client gets the english page. So it seems apache is adding
the parent languages in the "en fr" order (the one defined by
LanguagePriority). I would expect apache to add the parent languages in
the order they appear in the client request, so the user can get the
french page.

Tell me if you need more informations.

Thanks,

Vincent

----------------------------------------------------------

From: Richard Atterer <atterer@debian.org>
Subject: Issue with language negotiation exceptions [kind-of patch]

Hi,

just stopping by here on my search for a different bug...

As I read the docs (exactly the bit you quoted in the bug report!), Apache 
is behaving as described. However, its behaviour could be improved to be a 
bit more useful.

To the bug submitter: The only solution that I see for you ATM is to create 
symlinks for all language subsets that are important to you. For example, 
create a symlink called "index.fr-fr.html" which points to "index.fr.html".

To the maintainers:

The browser requests the languages "fr-fr,en-us;q=0.3", which is broken 
behaviour anyway as far as the HTTP standard is concerned; "fr" and 
"en;q=0.3" ought to be added.

When Apache sees that Accept-Language header, it cannot match it against 
the, say, index.en.html and index.fr.html files on disc. So the second part 
of the paragraph quoted in the bug report applies: The above list of 
language preferences is turned into

  "fr-fr,en-us;q=0.3,fr;q=0.001,en;q=0.001"

The order in this list does not matter, only the weight of each 
variant. So - oops: Suddenly fr and en have equal priority! :-(

At this point, the two available variants are in every practical aspect 
equally well-suited. Now the algorithm described on
<http://httpd.apache.org/docs/2.2/content-negotiation.html#algorithm>
will try to select one variant just to create a predictable, reproducible 
response. In our case, "en" sorts earlier alphabetically than "fr", so "en" 
is served.

The solution to this is: Do not use a quality value of 0.001 when adding 
the non-subset languages, but multiply the (implicit) 1.0 of fr-fr and the 
0.3 of en-us with 0.001.

Disclaimer: I'm not an Apache hacker, but having looked at the source for 
10 minutes, it appears the change would be inside set_language_quality() in 
modules/mappers/mod_negotiation.c. Instead of the line

  fiddle_q = 0.001f;
  
you'd want something similar to

  fiddle_q = 0.001f * accs[i].quality;

(completely untested)

Cheers,

  Richard

----------------------------------------------------------

I could reproduce the problem using a directory with index.fr.html and index.en.html
If I Accept-Language: fr-fr, en-gb and ask for index, I get served the english version
The patch fixes that.