Bug 54033

Summary: Parent languages are not ordered according to Accept-Language
Product: Apache httpd-2 Reporter: Nirgal Vourgère <jmv_deb>
Component: mod_negotiationAssignee: Apache HTTPD Bugs Mailing List <bugs>
Severity: enhancement Keywords: MassUpdate, PatchAvailable
Priority: P2    
Version: 2.2.21   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Attachments: Patch to order parent dialect according to client Accept-Language:

Description Nirgal Vourgère 2012-10-21 11:20:16 UTC
This problem has been report as Debian bug

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

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.




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


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


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
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)




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.
Comment 1 Eric Covener 2012-10-21 11:48:09 UTC
Changing to enhancement
Comment 2 Nirgal Vourgère 2012-10-21 12:10:17 UTC
Created attachment 29503 [details]
Patch to order parent dialect according to client Accept-Language:
Comment 3 William A. Rowe Jr. 2018-11-07 21:09:55 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.