55156 - localizable values are cached in the HTTP header

Status: VERIFIED WORKSFORME

(Core :: Networking, defect, P1)

Description

[tao]

accept-lang and locale part of the U-A string are localizable resources which
are stored in navigator.properties. Their values are retrieved and 'cached'
in HTTP header and never changed even when locale changed.

Please refer to http://bugscape.netscape.com/show_bug.cgi?id=2518 for details.

Comment 1

[tao]

We need this fixed by RTM to have browser and messenger send the right
accept-lang & U-A string to servers.

Comment 2

[tao]

Attachment: register callback for u-a-locale; flush strbulde earlier

Comment 3

[tao]

Add racham to review profile code and hyatt for moving the strbundle flush code.

Hi, Gagan/Warren:

Would you please review the HTTP Handler part?


I am also taking the bug over to speed up the process.

thx

Comment 4

[tao]

Add ftang for [rtm+ need info]

Comment 5

[tao]

the stringbundle flushing part is in (54784). Awaiting review for the
HTTPHandler part.

mark it P1.

Comment 6

[Gagan]

r=gagan

Comment 7

[Scott MacGregor]

Tao, your patch looks good to me.
sr=mscott

Comment 8

[tao]

Thanks to gagan, racham, and mscott for reviewing the code.

Hi, PDT:

please ++ this bug.


thx

Comment 9

[selmer (gone)]

Spoke to ftang, tao.

Looks like the bad thing here is that no profile can change it's locale - it
always gets the default installed locale.  Since the UA is affected, all
language tracking would become suspect.  This seems very serious.

On the other hand, this change is down in the guts and it's not a one-liner.
Please get this checked in on the branch and get several people to bang on it
for the next day and come back to us tomorrow with your results.  If people can
prove this fix is OK and no regressions occur we'll approve this.

Comment 10

[tao]

Fix checked in into the trunk.

IQA,

Please test it. 

Comment 11

[Phil Peterson]

marking [rtm need info] until IQA validates the patch on the trunk. Please mark
[rtm+] if it passes.

Comment 12

[msanz]

Tao, can you give us test cases? Bom-Shik, can you work with Tao to verify this
in the trunk today? We cannot wait more than Friday to get this into the branch.
Changing QA contact from tever to blee.

Comment 13

[tao]

Might I suggest that tever QA the US build w/ en-US pack and blee the US build
with en-DE pack? Thus, we have both sides covered.

Switch QA back to tever.

Comment 14

[Tom Everingham]

relevant headers for todays trunk builds en-US pack - looks good

WinNT 2000101208 -
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001012 
Netscape6/6.0b3
Accept: */*
Accept-Language: en

Mac 2000101208 -
User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; m18) Gecko/20001012 
Netscape6/6.0b3
Accept: */*
Accept-Language: en

Linux 2000101212 -
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.5-22 i686; en-US; m18) Gecko/20001012 
Netscape6/6.0b3
Accept: */*
Accept-Language: en

changing QA to blee

Comment 15

[tao]

Hi, QA:

Please download the langende.xpi to your local disk and use "File|Open File..."
to install it with nscp-2000-10-12-08-Mtrunk build.

To test the U-A string and accept-lang, goto "bubblegum:4321". You should see
"en-DE" in the u-a string and "de" in the accept-lang field.

Please let me know if you see any wierdness. If all go well, I'll request
PDT to approve the fix on the branch.


thx

Comment 16

[tao]

Please note that

1. In langende,xpi, I localized navigator.properties in en-DE.jar to show
   de home page, accept-lang and u-a string.
2. You need to switch to en-DE langpack, "View|Set Language/Region" to see
   the changes in (1).

Comment 17

[tao]

Oops, IQA, please use nscp-2000-10-12-08-Mtrunk build and the langende.xpi in
the URL field to test the patch. Sorry for missing out this note.

Comment 18

[blee]

Worked in 
Linux 101208Mtrunk >> User-Agent: en-DE, Accept-Language: de
WinNT 101208Mtrunk >> User-Agent: en-DE, Accept-Language: de
Had problem installing langende.xpi in Win NT - will further investigate.


Linux 101208Mtrunk
User-Agent: en-DE 
Accept-Language: de

Comment 19

[Phil Peterson]

[rtm++]

Comment 20

[tao]

patch checked in into the branch.

Comment 21

[blee]

Reopening as the latest en-DE pack shows Accept-Language: en. 

Linux 101808MN6 >> User-Agent: en-DE, Accept-Language: en
WinNT 101808MN6 >> User-Agent: en-DE, Accept-Language: en
Mac 101808MN6 >> User-Agent: en-DE, Accept-Language: en

Comment 22

[tao]

Those "en" values come from langpacks. Please log separate bugs to track this.
After discussion with Erik, the suggested values of accept-language in
langpacks are:

   en-*: en
   de-*: de
   fr-*: fr

In this case, it is correct for en-DE to have "en" as the value of accept-lang.

Comment 23

[blee]

Marking Verified per tao's comment.