[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#288615: marked as done (apache2: Issue with language negotiation exceptions)

Your message dated Mon, 29 Sep 2014 22:56:13 +0200
with message-id <1939381.NcvIMBtSle@k>
and subject line Re: Bug#157734: workaround for wrong Accept-Language headers
has caused the Debian Bug report #157734,
regarding apache2: Issue with language negotiation exceptions
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
157734: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=157734
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: apache2
Version: 2.0.52-3
Severity: normal


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

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (991, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Versions of packages apache2 depends on:
ii  apache2-mpm-prefork           2.0.52-3   Traditional model for Apache2

-- no debconf information

--- End Message ---
--- Begin Message --- 
Version: 2.4.1-1

On Sunday 20 December 2009 01:52:44, Stefan Fritsch wrote:
> > We want the first user priority to be honored, even if we can't
> > satisfy it in a specific manner.
> 
> A partial workaround is possible with this mod_headers command:
> 
> RequestHeader edit Accept-Language
> "(^\s*|,\s*)(\w\w)-(\w\w)([^,]*)(,|$)"  "$1$2-$3$4, $2$4$5" early
> 
> This adds the corresponding generic language after the first
> non-generic  language, e.g "en-us" will become "en-us, en", or
> "en-us; q=0.4" will become "en-us; q=0.4, en; q=0.4".
> 
> This is only a partial workaround since it will only do what you
> want if  the languages are sorted with highest preference first
> (which need not be the case). I don't know how many browsers do
> this, but maybe you want to try it? At least for iceweasel it seems
> to work.
> 
> A complete fix would be possible with some global-edit command
> (which does  not exist yet).

There is now a global variant of edit, named "edit*". This should 
allow to configure the requested behavior.

--- End Message ---
Reply to: