1285961 - HTTP-header does not transmit intl.accept_languages

Status: RESOLVED DUPLICATE of bug 1005640

(Core :: Networking: HTTP, defect)

Description

[g2360673]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160612154351



Actual results:

HTTP-header does not transmit intl.accept_languages


Expected results:

chrome/ru/locale/ru/global/intl.properties ->

intl.accept_languages = ru-RU, ru, en-US, en

remove gaps.

Comment 1

[Michal Novotny [:michal]]

If I set intl.accept_languages in preferences then everything works as expected, so the problem is definitely not in necko code.

Comment 2

[Axel Hecht [:Pike]]

kolchin, can you add some more detail on what platform you're on and how you test?

This is not a localization bug, it's either networking or the actual russian localization. If this is on linux, it might also be a dupe of bug 1005640. Tentatively moving back to networking, I'll keep following to see what the actual problem is. If this is another problem of how to deal with the localized defaults, we'll need to also fix this in networking.

Comment 3

[Daniel Stenberg [:bagder]]

This needs to be elaborated or closed (as a dupe) I think.

This problem is said to still be a networking bug, but we've not reproduced a problem but only verified that necko will in fact send the accept headers according to the pref. I tried just now too and it seems to behave.

Comment 4

[Axel Hecht [:Pike]]

Bug 1005640 comment 15 is the best explanation of how the pref gets disconnected from the pref.

Looking back at the user agent in comment 0, it says linux, so yes, probably a dupe of bug 1005640. I'd still like to hear from kolchin on whether this is the system that he tested.