191946 - shows japanese language, instead of english

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P3)

Description

[Jeff Bhav]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030202
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030202

I have mozilla settings under Edit -> Preferences -> Languages with all
languages enabled.

When i visit the above URL, it shows me the page in Japanese Language. While the
same URL on IE6.0 shows me english.

Reproducible: Always

Steps to Reproduce:
1. Go to http://httpd.apache.org/docs/windows.html
2. View Page.
3.

Actual Results:  
It renders the page in Japanese.

Expected Results:  
It should render the page in English.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> with all languages enabled.

In what order?  If you have "ja" ranked higher than "en" the server will send
the page in Japanese, since you're saying you prefer it.

Comment 2

[Jeff Bhav]

My option are starting like this...
English/United Stats [en-us]
English [en]
Afrikaans [af]
.
.
.
Zulu [zu]

Comment 3

[Boris Zbarsky [:bzbarsky]]

hmm.. sounds like you just have so many entries that we don't send a useful q
value and the server randomly picks a language....

Could do the following?

set NSPR_LOG_MODULES=nsHttp:5
set NSPR_LOG_FILE=c:\log.txt

start mozilla from that terminal, load that one page, quit mozilla.  Then attach
the resulting log to this bug using
http://bugzilla.mozilla.org/attachment.cgi?bugid=191946&action=enter ?

Comment 4

[Jeff Bhav]

I have created the log file, but when i use the URL:
http://bugzilla.mozilla.org/attachment.cgi?bugid=191946&action=enter 
and press OK, I get this error:

Software error:

Malformed multipart POST

For help, please send mail to the webmaster ([e-mail]), giving this
error message and the time and date of the error. 

So i can't upload.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Mail it to me directly?

Comment 6

[Boris Zbarsky [:bzbarsky]]

The relevant part of the log is the following header:

Accept-Language:
en-us,en;q=0.10,af;q=0.10,sq;q=0.10,ar;q=0.10,ar-dz;q=0.10,ar-bh;q=0.10,ar-eg;q=0.9,ar-iq\
;q=0.9,ar-jo;q=0.9,ar-kw;q=0.9,ar-lb;q=0.9,ar-ly;q=0.9,ar-ma;q=0.9,ar-om;q=0.9,ar-qa;q=0.\
9,ar-sa;q=0.9,ar-sy;q=0.9,ar-tn;q=0.9,ar-ae;q=0.9,ar-ye;q=0.8,hy;q=0.8,ast;q=0.8,eu;q=0.8\
,be;q=0.8,bs;q=0.8,bg;q=0.8,ca;q=0.8,zh;q=0.8,zh-cn;q=0.8,zh-hk;q=0.8,zh-sg;q=0.8,zh-tw;q\
=0.8,hr;q=0.7,cs;q=0.7,da;q=0.7,nl;q=0.7,nl-be;q=0.7,en-au;q=0.7,en-bz;q=0.7,en-ca;q=0.7,\
en-ie;q=0.7,en-jm;q=0.7,en-nz;q=0.

Quite apart from us truncating it, how did we end up with 0.9 when we mean 0.09,
etc?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Oh, it's because of the bizarre way we create the string.... say q=0.09.  We add
0.05, multiply by 10, cast to unsigned int (that gives us 9).  then we printf it
in as follows

PR_snprintf(p2, available, "%s%s;q=0.%01u", comma, token, QVAL_TO_UINT(q));

This means that we get q=0.9

Why not just do q=%.2f for the format instead of mucking with this unsigned int
business?

Comment 8

[Darin Fisher]

bz: please look away from that function.  it is ugly.  i think i probably caused
this regression several months back when i checked in changes to reduce the
length of the Accept-Language header.  i also don't see any reason for all the
integer gobbly-goo.

Comment 9

[Darin Fisher]

-> suresh

Comment 10

[Suresh]

I couldn't duplicate this bug when I added all the languages in Edit | Pref |
Navigator | languages. 

I'm trying to see whether I can duplicate this using the language order and/or
count mentioned in comment#6.

Comment 11

[Suresh]

ok, i couldn't duplicate this using the language set/order in comment #6. 

However, looking at the code and bz's comment, it makes sense to me to change
that line to 

wrote = PR_snprintf(p2, available, "%s%s;q=%.02f", comma, token, q);

Using this, the Accept-Language header looks like,
Accept-Language:
en-us,en;q=0.98,af;q=0.95,sq;q=0.93,ar;q=0.91,ar-dz;q=0.89,ar-bh;q=0.86,ar-eg;q=0.84.....


darin/bz: does this looks ok to you? thanks!

Comment 12

[Boris Zbarsky [:bzbarsky]]

Those q values seem too high by a factor of 10 if we're still trying to have
them all add up to 1....

Comment 13

[Suresh]

Attachment: take one ;-)

patch to explicitly add q-value to be 1.0 for the first language (i.e
en-us;q=1.0,en;q=0.9)

Comment 14

[Darin Fisher]

suresh: q=1.0 is implied if not specified.  specifying it is therefore just
extra bytes to transfer needlessly.  the real bug here is that we print q=0.1
for things that shouldn't have that low of a q-value.

Comment 15

[Suresh]

Attachment: patch

I think rounding the q value (particularly with larger values like 0.988) is
the reason why we generate such low value of q.

Comment 16

[Darin Fisher]

yeah, good catch... but, i think it's just a matter of matching the way we round
up to the branch in the code:

  if (q < 0.9995)
      PR_snprintf(..., "%s%s;q=0.%01u", ..., QVAL_TO_UINT(q));

seems to me that we should round first, then branch |if (q < 10)|.  like this:

  u = QVAL_TO_UINT(q);
  if (u < 10)
      PR_snprintf(..., "%s%s;q=0.%u", ..., u);

i think this would also make the code easier to read =)

Comment 17

[Suresh]

darin, if I use your above solution, there can be cases (depending on number of
languages) where some languages have no q value. 

If I choose all the languages, the Accept-Language header looks like, 
en-us,en,af,sq,ar,ar-dz,ar-bh,ar-eq;q=o.9,ar-iq;q=0.9.....

will this be ok? 

Comment 18

[Suresh]

Attachment: updated patch

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 118351 [details] [diff] [review]
updated patch

r=biesi if you move the |u| declaration to the line where you use that variable
(like this:
PRUint32 u = QVAL_TO_UINT(q);
)

Comment 20

[Darin Fisher]

Comment on attachment 118351 [details] [diff] [review]
updated patch

so this pattern is repeated in several other places as well.  please fix all of
them.  thx!

Comment 21

[Suresh]

Attachment: patch to fix the bug in all places.

Comment 22

[Darin Fisher]

Comment on attachment 118464 [details] [diff] [review]
patch to fix the bug in all places.

thanks suresh.. looks great!  sr=darin

Comment 23

[Suresh]

fixed in trunk.