GNOME Bugzilla – Bug 617365
Accept-Language has priority over language cookie
Last modified: 2018-09-24 10:13:42 UTC
Here is how to reproduce the bug: - entered the library.gnome.org website (you'll be on the home tab displayed in English) - click on a different language from the right column (the home tab will be displayed in the chosen language) - click on a different tab (i.e. Users, the second one) - ! the tab is displayed in English again ! Now, if you go back to Home, it will still be in English, but if you refresh the page with the browser button, the language you selected in step 2 will be used again. See a screencast here: http://www.youtube.com/watch?v=IPn3iGQj_V8
It looks like a caching problem in your browser (or an eventual proxy); I just checked and library.gnome.org sends a correct Vary header (set to both Accept-Language and Cookie). This makes it so the "users" page you have in cache should *not* be used once you go back to that page with a new cookie set. Are you using a proxy somewhere? Could you try with another browser?
I don't have any proxy set and I experienced the same behavior with Google Chrome and Firefox too.
What about using web inspector to monitor requests and their headers? Also, what happens when you use your browser language selector to switch language, instead of using the language links?
I can't dig into that now, but I'll be happy to do it another day. If you like I'll be available to share my desktop with you and debug it together. I tried to se Firefox only preferred language to Arabic but the problem remains.
I have same problem for this, and I don't have proxy. My language is zh_CN, I also checked the cookie, it's set to zh_CN already. When I click zh_CN in Available language, the HTTP Response header is : Date: Thu, 15 Jul 2010 08:26:21 GMT Server: Apache/2.2.3 (Red Hat) Last-Modified: Thu, 15 Jul 2010 06:54:25 GMT Etag: "50cdd-23f7-92a4aa40" Accept-Ranges: bytes Content-Length: 9207 Vary: Cookie Content-Type: text/html; charset=UTF-8 200 OK When I click any other link then, the HTTP Response header is: Date: Thu, 15 Jul 2010 08:27:51 GMT Server: Apache/2.2.3 (Red Hat) Content-Location: index.html.en_GB Vary: negotiate,accept-language,Cookie TCN: choice Last-Modified: Thu, 15 Jul 2010 07:02:20 GMT Etag: "e8ae2-25d1-aef49700" Accept-Ranges: bytes Content-Length: 9681 Content-Type: text/html; charset=UTF-8 Content-Language: en-gb 200 OK It is back to English again.
*** Bug 624431 has been marked as a duplicate of this bug. ***
*** Bug 620035 has been marked as a duplicate of this bug. ***
Is there any update on this bug? The STATUS is NEEDINFO, but what exactly information you need us to provide to help you solve this bug? And is there anything I can help to fix this one? Thanks.
Many replies, and even 2 duplicate bug report, how to make this bug UNCONFIRMED? Half year from the last post, this bug is still there. Could anyone here spent some time to fix this bug? or provide a pointer to which part of the code are affected, and make it easier for others to fix this bug? Thanks. I don't know what else information you need. I paste the data from developer tools in Chrome here. It clearly shows the bug. ======================================== Request URL:http://library.gnome.org/devel/guides Request Method:GET Status Code:200 OK ======================================== Request Headers Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Charset:GBK,utf-8;q=0.7,*;q=0.3 Accept-Encoding:gzip,deflate,sdch Accept-Language:zh-CN,zh;q=0.8 Connection:keep-alive Cookie:language=zh_CN Host:library.gnome.org Referer:http://library.gnome.org/devel/index.html.zh_CN User-Agent:Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.127 Safari/534.16 ======================================== Response Headers Accept-Ranges:bytes Connection:close Content-Language:en Content-Length:15205 Content-Location:guides.html.en Content-Type:text/html; charset=UTF-8 Date:Tue, 08 Mar 2011 23:48:04 GMT ETag:"e8acb-3b65-1e8485c0;5d2e5480" Last-Modified:Tue, 08 Mar 2011 23:39:11 GMT Server:Apache/2.2.3 (Red Hat) TCN:choice Vary:negotiate,accept-language,Cookie ======================================== Referer:http://library.gnome.org/devel/index.html.zh_CN means, current page is zh_CN. Cookie:language=zh_CN means, cookie is in the Request Headers. Content-Language:en Content-Location:guides.html.en Means the server-side code cannot read the provided cookie, and return the default English site.
Tao: Thanks, those headers are very helpful. Made the following Apache configuration change: > -AddLanguage zh-CN .zh-cn > +AddLanguage zh-CN .zh_CN > +AddLanguage zh_CN .zh_CN One for the language set via a cookie, one for the browser language. Could you check in 30min+ (takes at least 30min before configuration change is applied on the server). Not sure if this would fix it for you, assume so.
Hi, Olav, Thank you very much, it works for zh_CN now. good job. I also tested on Bug 620035, it's still not working for (pl). Here is what I got from web developer tools in Chrome: ======================================== Request URL:http://library.gnome.org/ Request Method:GET Status Code:200 OK ======================================== Request Headers Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Charset:GBK,utf-8;q=0.7,*;q=0.3 Accept-Encoding:gzip,deflate,sdch Accept-Language:pl,zh-CN;q=0.8,zh;q=0.6 Connection:keep-alive Cookie:language=pl Host:library.gnome.org Referer:http://library.gnome.org/users/index.html.pl User-Agent:Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.127 Safari/534.16 ======================================== Response Headers Accept-Ranges:bytes Connection:close Content-Language:zh_cn Content-Length:9127 Content-Location:index.html.zh_CN Content-Type:text/html; charset=UTF-8 Date:Thu, 10 Mar 2011 15:42:23 GMT ETag:"50cdd-23a7-c92aa580" Last-Modified:Thu, 10 Mar 2011 13:25:58 GMT Server:Apache/2.2.3 (Red Hat) TCN:choice Vary:negotiate,accept-language,Cookie ======================================== Current page is in pl, and request the http://library.gnome.org/, and it's back to zh_CN. I think apache try to find out the correct language file based on 'Accept-Language' header, which is "Accept-Language:pl,zh-CN;q=0.8,zh;q=0.6" in this case. Apache cannot found pl, so it turns to zh-CN. So, I think there might be more language than zh_CN need to be corrected in the apache configuration file. Could you double check the apache's configuration against the lang-code in the language option sidebar of the home page? It might be fix the Bug 620035 along with other unreported bug for other languages. Thank you.
Hmm, seems to work for PL at least for me. Also I can switch languages and they stay switched.
It's not work for me for PL. And it's not work for many other languages. Such as, af, ar, ast, be@latin, ca@valencia, en_GB, pt_BR, zh_HK, zh_TW. I didn't test all of languages, but at least the languages above is not working. Could you provide the output of web developer tools about the HTTP request header and response header? And which browser are you using? So, maybe I can find out the different between us.
Hmm, seems like about/about isn't working in all cases and language codes in form "lang@something" I'm using Firefox 4.0 RC on Win32 and Ubuntu 11.04 (Request-Line) GET /devel/ HTTP/1.1 Host library.gnome.org User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language pl,en-us;q=0.7,en;q=0.3 Accept-Encoding gzip, deflate Accept-Charset ISO-8859-2,utf-8;q=0.7,*;q=0.7 Keep-Alive 115 Connection keep-alive Cookie language=sr@latin If-Modified-Since Sat, 12 Mar 2011 04:50:56 GMT If-None-Match "e8cc5-2610-d2f24c00" Cache-Control max-age=0 (Status-Line) HTTP/1.1 304 Not Modified Date Sat, 12 Mar 2011 10:40:27 GMT Server Apache/2.2.3 (Red Hat) Connection close Etag "e8cc5-2610-d2f24c00" Content-Location index.html.pl Vary negotiate,accept-language,Cookie
The cause is a mismatch between the default language options set by Apache, and what it actually used in practice on library.gnome.org. There needs to be language mappings from: 1. Accept-Language -> file extension used on library.gnome.org 2. File extension -> file extension used on library.gnome.org Below is configuration on the server (CUSTOM is what has been added before, but changes have already been made before that line): AddLanguage ca .ca AddLanguage cs .cz .cs AddLanguage da .dk AddLanguage de .de AddLanguage el .el AddLanguage en .en AddLanguage eo .eo AddLanguage es .es AddLanguage et .et AddLanguage fr .fr AddLanguage he .he AddLanguage hr .hr AddLanguage it .it AddLanguage ja .ja AddLanguage ko .ko AddLanguage ltz .ltz AddLanguage nl .nl AddLanguage nn .nn AddLanguage no .no AddLanguage pl .pl AddLanguage pt .pt AddLanguage pt-BR .pt-br AddLanguage ru .ru AddLanguage sv .sv AddLanguage zh-CN .zh_CN AddLanguage zh_CN .zh_CN AddLanguage zh-TW .zh-tw # CUSTOM: AddLanguage tr .tr AddLanguage pt-br .pt_BR AddLanguage en-gb .en_GB AddLanguage mk .mk AddLanguage pa .pa AddLanguage th .th AddLanguage hu .hu AddLanguage uk .uk AddLanguage eu .eu AddLanguage af .af AddLanguage sq .sq AddLanguage be@latn .be@latn e.g. sr@latin is not in this list (likely a lot of others are not in there as well), so I need to know: 1. The Accept-Language code for sr@latin 2. The extension on library.gnome.org for sr@latin I can figure above myself out, but that'll take quite some time (busy).
Could you put the 'AddLanguage' section to .htaccess, and put the file into the git repository? So, I can create a patch against it. I think there are lot of languages are missing, and many need to be modified in the above list.
Created attachment 183232 [details] httpd.conf Server configuration is in Git. Just nothing accessible from anyone but sysadmins. I've attached the httpd.conf file.
Anyway, before I post the list of the additional 'AddLanguage' lines, please remove the following lines in the above list: AddLanguage pt-BR .pt-br AddLanguage zh-TW .zh-tw The extension is not exist, and will be fixed in the following lines. According to /data/languages.xml, I create a missing list of AddLanguage: =========================== AddLanguage af .af AddLanguage ar .ar AddLanguage sq_AL .sq_AL AddLanguage hy_AM .hy_AM AddLanguage az_AZ .az_AZ AddLanguage eu_ES .eu_ES AddLanguage be_BY .be_BY AddLanguage be@latin .be@latin AddLanguage bn_BD .bn_BD AddLanguage bn_IN .bn_IN AddLanguage bg_BG .bg_BG AddLanguage bs_BA .bs_BA AddLanguage ca_ES .ca_ES AddLanguage zh_HK .zh_HK AddLanguage zh_SG .zh_SG AddLanguage zh_TW .zh_TW AddLanguage zh .zh_CN AddLanguage zh-HK .zh_HK AddLanguage zh-SG .zh_SG AddLanguage zh-TW .zh_TW AddLanguage hr_HR .hr_HR AddLanguage cs_CZ .cs_CZ AddLanguage da_DK .da_DK AddLanguage nl_NL .nl_NL AddLanguage nl_BE .nl_BE AddLanguage en_US .en_US AddLanguage en_AU .en_AU AddLanguage en_GB .en_GB AddLanguage en_CA .en_CA AddLanguage en_IE .en_IE AddLanguage en_DK .en_DK AddLanguage en_ZA .en_ZA AddLanguage en_MT .en_MT AddLanguage en_NZ .en_NZ AddLanguage et_EE .et_EE AddLanguage fi_FI .fi_FI AddLanguage fr_FR .fr_FR AddLanguage fr_BE .fr_BE AddLanguage fr_CA .fr_CA AddLanguage fr_LU .fr_LU AddLanguage fr_CH .fr_CH AddLanguage gl_ES .gl_ES AddLanguage de_DE .de_DE AddLanguage de_AT .de_AT AddLanguage de_LU .de_LU AddLanguage de_CH .de_CH AddLanguage el_GR .el_GR AddLanguage el_CY .el_CY AddLanguage gu_IN .gu_IN AddLanguage he_IL .he_IL AddLanguage iw_IL .iw_IL AddLanguage hi_IN .hi_IN AddLanguage hu_HU .hu_HU AddLanguage id_ID .id_ID AddLanguage ga_IE .ga_IE AddLanguage it_IT .it_IT AddLanguage ja_JP .ja_JP AddLanguage kn_IN .kn_IN AddLanguage rw_RW .rw_RW AddLanguage ko_KR .ko_KR AddLanguage lv_LV .lv_LV AddLanguage lt_LT .lt_LT AddLanguage ms_MY .ms_MY AddLanguage ml_IN .ml_IN AddLanguage mn_MN .mn_MN AddLanguage nso_ZA .nso_ZA AddLanguage no_NO .no_NO AddLanguage nn_NO .nn_NO AddLanguage fa_IR .fa_IR AddLanguage pl_PL .pl_PL AddLanguage pt_PT .pt_PT AddLanguage pt_BR .pt_BR AddLanguage ro_RO .ro_RO AddLanguage ru_RU .ru_RU AddLanguage sr .sr AddLanguage sr@Latn .sr@Latn AddLanguage sr@latin .sr@latin AddLanguage sr@ije .sr@ije AddLanguage sh_BA .sh_BA AddLanguage sk_SK .sk_SK AddLanguage sl_SI .sl_SI AddLanguage es_ES .es_ES AddLanguage es_AR .es_AR AddLanguage es_BO .es_BO AddLanguage es_CL .es_CL AddLanguage es_CO .es_CO AddLanguage es_CR .es_CR AddLanguage es_EC .es_EC AddLanguage es_GT .es_GT AddLanguage es_MX .es_MX AddLanguage es_NI .es_NI AddLanguage es_PA .es_PA AddLanguage es_PE .es_PE AddLanguage es_PY .es_PY AddLanguage es_SV .es_SV AddLanguage es_UY .es_UY AddLanguage es_VE .es_VE AddLanguage sv_SE .sv_SE AddLanguage sv_FI .sv_FI AddLanguage th_TH .th_TH AddLanguage tr_TR .tr_TR AddLanguage uk_UA .uk_UA AddLanguage vi_VN .vi_VN AddLanguage wa_BE .wa_BE AddLanguage cy_GB .cy_GB AddLanguage xh_ZA .xh_ZA AddLanguage yi .yi AddLanguage zu_ZA .zu_ZA AddLanguage oc .oc =========================== And, I think this should be part of library-web, so please add the .htaccess, which contains 'AddLanguage' list, to the git repository. Thanks.
Sorry for the last post, I didn't get your post before I submit it. I think, move the AddLanguage section to .htaccess, and put it to library-web repository, and during the build the website, the .htaccess is automatically copied to the website's root, might be the better idea. They are library-web specified, and it's not nessesary to be secured, and should be modified togather with languages.xml. So, anyone can access languages.xml should be able to access the 'AddLanguage' section too.
Sorry, I might be wrong, the /data/languages.xml seems not exactly match the file extension. Please hold to apply the list to httpd.conf. I need a few minutes to verify it. In the mean time, do you know which file contain's the file extension list for different language?
.htaccess is a bad idea: 1) would only fix library-web, not anything else (e.g. gnome3.org.. it uses the same method) 2) I don't want to hand out the permissions needed to change AddLanguage (FileInfo) Fixing in one place is way better. Regarding file extensions and language matching: no idea. Maintainer (frederic peters) has to comment.
Created attachment 183233 [details] [review] patch for add more languages mapping to httpd.conf Hi, I recreate the patch against the 'httpd.conf' in your post. This time, it should be correct. I'm using the language list in the index page of library.gnome.org.
I'm sorry if my last post didn't make it clear. The 'AddLanguage' list in comment 18 should be ignored, since they are not match the file extensions. The patch in comment 22 should be applied, since they are match the language list in the generated index.html. I'm not quite sure after the patching, whether the list is completed or not, however, the modifications in the patch should fix most of the problem. So, it's ok to apply. The only thing left before close this bug is that someone who familiar with the code may need verify whether there is any other language is missing.
Is there any update with this bug? Did the patch applied? Anyway, I found another reason caused this bug. If the Accept-Language header contains languages in LanguagePriority(httpd.conf), than the server sometimes will ignore other user specified preference, even ignore the quality value set by browser, and just follow the LanguagePriority. And sometimes, the server doesn't follow the LanguagePriority and follow the Accept-Language. I cannot figure out the pattern, but it's not work as it should be. For example, I tested following cases (using WFetch tools): 1) [Request] Accept-Language: zh-cn,zh;q=0.7,en-us;q=0.3\r\n Cookie: language=zh_CN\r\n [Response] Content-Location: index.html.en_GB\r\n 2) Just modify the Cookie from 'zh_CN' to 'zh-CN' [Request] Accept-Language: zh-cn,zh;q=0.7,en-us;q=0.3\r\n Cookie: language=zh-CN\r\n [Response] Content-Location: index.html.en_GB\r\n 3) Set cookie to 'zh-cn'. [Request] Accept-Language: zh-cn,zh;q=0.7,en-us;q=0.3\r\n Cookie: language=zh-cn\r\n [Response] Content-Location: index.html.en_GB\r\n 4) Remove zh-cn in Accept-Language. [Request] Accept-Language: zh;q=0.7,en-us;q=0.3\r\n Cookie: language=zh-cn\r\n [Response] Content-Location: index.html.en_GB\r\n 5) Change zh to zh-cn in Accept-Language [Request] Accept-Language: zh-cn;q=0.7,en-us;q=0.3\r\n Cookie: language=zh-cn\r\n [Response] Content-Location: index.html.en_GB\r\n 6) Then, remove en-us from Accept-Language. This time, it finally get correct zh_CN page. [Request] Accept-Language: zh-cn;q=0.7\r\n Cookie: language=zh-cn\r\n [Response] Content-Location: index.html.zh_CN\r\n 7) Also, I tested to reduce the en-us's quality value, which should be used for content negotiation. But get no luck. [Request] Accept-Language: zh-cn;q=0.7,en-us;q=0.1\r\n Cookie: language=zh-cn\r\n [Response] Content-Location: index.html.en_GB\r\n 8) And I tested modify the zh-cn to zh_CN in Accept-Language, and, suprisingly, it get zh_CN page again. [Request] Accept-Language: zh_CN;q=0.7,en-us;q=0.3\r\n Cookie: language=zh_CN\r\n [Response] Content-Location: index.html.zh_CN\r\n 9) I also tested pt-BR in Accept-Language and zh_CN in Cookie, which is share same pattern of zh-CN. It returns pt_BR page. Not the language specified. [Request] Accept-Language: pt-BR;q=0.7,en-us;q=0.3\r\n Cookie: language=zh_CN\r\n [Response] Content-Location: index.html.pt_BR\r\n 10) Before you make a conclusion, that server only return the language accepted in Accept-Language header, the following case doesn't follow it. pt-BR and en-us in Accept-Language, pl in Cookie, and server returns pl page.: [Request] Accept-Language: pt-BR;q=0.7,en-us;q=0.3\r\n Cookie: language=pl\r\n [Response] Content-Location: index.html.pl\r\n I don't where is the problem, but it's definitely something wrong. Sometimes the server follow the Cookie, sometimes it follows LanguagePriority in httpd.conf, and sometimes it follows Accept-Language and ignore Cookie. Could anyone give some help here?
Tao: Only applied just now. I wanted to check the patch and didn't have time up to now.
Case 9 still fails... I think it is to do with the 'LanguagePriority' setting. Haven't figured out what the interaction is.
Updating the bug description as there's now a single particular case that is failing.
Hello there. I'm coordinator for Brazilian Portuguese (pt_BR) language team, and I'm currently not able to see help.gnome.org in pt_BR, exactly as describe in the original post. I tested setting Google Chrome's UI to Spanish and I worked just fine, which doesn't happen with pt_BR. Can anyone please verify this? Page accessed: https://help.gnome.org/misc/release-notes/3.18/
Currently, browsing https://help.gnome.org/ and https://developer.gnome.org/ provides my pt, but pt_BR was expected. If I switch language to pt_BR, I'll go back to home page as pt_BR, but accessing any link will return me to pt. Not sure if related to this issue.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/Infrastructure/Websites/issues/40.