80020 - Accept_Language and Accept_Charset format error

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P2)

Description

[Benoit Maisonny]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i686; en-US; rv:0.9) Gecko/20010505
BuildID:    2001050921

Depending on the locale, Accept_Language and Accept_Charset have an incorrect
format regarding the quality attribute. With a fr_FR locale, i have
Accept-Language: fr, en-us; q=0,750, en; q=0,500, nl; q=0,250. The correct
format would be Accept-Language: fr, en-us; q=0.750, en; q=0.500, nl; q=0.250
(decimal POINT rather than the locale COMMA).

Reproducible: Always
Steps to Reproduce:
1. Set your locale to fr_FR (on Linux/bash I do 'export LANG=fr_FR').
2. Start Mozilla (within the shell where you changed the locale)
3. Make sure you have at least 2 accepted languages in
Edit/Preferences/Navigator/Languages.
4. Start an HTTP request, for example to my demonstration page
http://milkyweb.com/mozilla/h.php


Actual Results:  The Web server receives the HTTP headers wrongly formatted, as in:
Accept-Language: fr, en-us; q=0,750, en; q=0,500, nl; q=0,250

Expected Results:  The right format:
Accept-Language: fr, en-us; q=0.750, en; q=0.500, nl; q=0.250

Reference : RFC 2068, HTTP/1.1 page 97-99.
I'm using Linux/Suse 7.1.

Comment 1

[Keyser Sose]

Marking NEW this is also sen in Mail/NEws X-Acceptted Languages as per bug 66734
which i am marking as a dupe.

Comment 2

[Keyser Sose]

*** Bug 66734 has been marked as a duplicate of this bug. ***

Comment 3

[Benoit Maisonny]

As this is now assigned to the Internationalization component, I would like to
add a comment:
I think the I18N does its job well. It's just that these 2 HTTP headers (and
possibly all headers, but I'm not sure) should not be localized at all. They
should follow the HTTP protocol syntax.
Well, you know better than me which component to assign to, but i wanted to be
clear.

Another note: I tested this with Mozilla 0.9 on WinNT4 SP6 and the headers are
correctly formatted with my locale settings.

Comment 4

[nhottanscp]

Adding momoi to cc who knows about this very well.
Momoi san, any change around this area since NS6?

Comment 5

[Benoit Maisonny]

NS6 (and Mozilla 0.8 if i remember well) did not set the quality value on
accepted languages.

Here's what i have with NS6 (Mozilla/5.0 (X11; U; Linux 2.2.14-6.1.1smp i686;
en-US; m18) Gecko/20001107 Netscape6/6.0):

Accept-Language: fr, en
Accept-Charset: 

(using my example URL above)

Comment 6

[nhottanscp]

Reassign to [e-mail].

Comment 7

[Katsuhiko Momoi]

The Q-values decimal point is indeed susceptible to 
LC_NUMERIC value differences. (5/15/2001 Linux build).
I don't think this is an localization issue. The problem
seems to be an i18n one. Other HTTP headers sent, e.g.
User_Agent string does not have this problem under
fr_FR locale.

Comment 8

[Adrian Havill]

The following patch should fix the comma/dot I18N issue with the HTTP protocol.
As this affects the protocol, this should be fixed ASAP.

I need a r= and sr= please.

Comment 9

[Adrian Havill]

Attachment: Avoids use of locale sensitive %f in printf

Comment 10

[Adrian Havill]

Ugh! Missed one character in the last patch! I blame the keyboard. Use the next
patch.

need a sr= and r=, and then someone to check it in please.

Verify the output with:

http://www.mozilla.gr.jp:4321/

Comment 11

[Adrian Havill]

Attachment: changed the locale sensitive %f to a %u (revised from prev patch)

Comment 12

[Darin Fisher]

this looks good to me (sr=darin), but while you're at it why not reduce the
precision?  do we really need 3 decimal places?

Comment 13

[Adrian Havill]

Darin Fisher wrote:
> this looks good to me (sr=darin), but while you're at it why not reduce the
> precision?  do we really need 3 decimal places?

Not really, unless the user adds more than 99 languages (and even if they do
this, protocol wise the sent request will still be syntax-correct). ;-P. Will
reduce to 2 decimal places. Please check in the next patch.

Comment 14

[Adrian Havill]

Attachment: locale-insensitive floating point nums for HTTP request Q attrs (2 significant digits)

Comment 15

[Darin Fisher]

sr=darin

Comment 16

[Darin Fisher]

-> me, so i can get this checked in.

Comment 17

[Bradley Baetz (:bbaetz)]

r=bbaetz

Comment 18

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 19

[Darin Fisher]

fix checked in

Comment 20

[Yuying Long]

Verified it shows decimal point(dot) not comma on 06-13 trunk build.

Comment 21

[neeti]

*** Bug 77700 has been marked as a duplicate of this bug. ***