|Summary:||Parent languages are not ordered according to Accept-Language|
|Product:||Apache httpd-2||Reporter:||Nirgal Vourgère <jmv_deb>|
|Component:||mod_negotiation||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|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 http://bugs.debian.org/288615 From: Vincent Untz <email@example.com> 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 <firstname.lastname@example.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.
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.