GNU bug report logs - #46807
[website] return 404 with HTTP header 'Accept-Language: zh-CN,zh'

Previous Next

Package: guix;

Reported by: ylc991 <ylc991 <at> 163.com>

Date: Sat, 27 Feb 2021 02:45:02 UTC

Severity: normal

Done: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: ylc991 <ylc991 <at> 163.com>
Cc: 46807 <at> debbugs.gnu.org
Subject: bug#46807: [website] return 404 with HTTP header 'Accept-Language: zh-CN, zh'
Date: Sat, 27 Feb 2021 13:31:40 +0100
[Message part 1 (text/plain, inline)]
Ylc991,

Thanks for the report!

My verbose notes so far; I need to (finally!) set up a local build 
of the Web site first.

ylc991 写道:
> Hello! My webbrowser has set ‘Accept-Language’ to 'zh-CN,zh' by 
> default, and https://guix.gnu.org returns 404.

Indeed, handling of zh-CN specifically is broken.  :-(

--8<---------------cut here---------------start------------->8---
~ λ curl -LI -H 'Accept-Language: zh-cn' https://guix.gnu.org
HTTP/1.1 404 Not Found
[...]
--8<---------------cut here---------------end--------------->8---

This is because our nginx configuration 
(maintenance/hydra/nginx/berlin.scm) does:

--8<---------------cut here---------------start------------->8---
set_from_accept_language $lang en de es fr zh-CN;
[...]
try_files $uri /$lang/$uri /$lang/$uri/index.html =404;
--8<---------------cut here---------------end--------------->8---

i.e., it looks in /srv/guix.gnu.org/zh-CN, but our website uses...

--8<---------------cut here---------------start------------->8---
nckx <at> berlin ~$ ls -d /srv/guix.gnu.org/zh*
/srv/guix.gnu.org/zh-cn/
--8<---------------cut here---------------end--------------->8---

...lowercase.  This questionable choice comes from 
artwork/po/ietf-tags.scm:

--8<---------------cut here---------------start------------->8---
;;; This file contains an association list for each translation 
   from
;;; the locale to an IETF language tag to be used in the URL path 
   of
;;; translated pages.  The language tag results from the 
   translation
;;; team<E2><80><99>s language code from
;;; <https://translationproject.org/team/index.html>.  The 
   underscore
;;; in the team<E2><80><99>s code is replaced by a hyphen.  For 
   example, az would
;;; be used for the Azerbaijani language (not az-Latn) and zh-CN 
   would
;;; be used for mainland Chinese (not zh-Hans-CN)
([...]
("zh_CN" . "zh-cn"))
--8<---------------cut here---------------end--------------->8---

Questionable only because, while a lowercase region is technically 
valid, it's so rare that it's likely to cause problems -- as we 
found out.

> I have tested with curl, 'zh-CN,zh', 'zh-CN', [is 404]

These are valid, so the nginx accept-language module accepts them, 
but then looks for a subdirectory that doesn't exist and returns 
404.

> 'zh-cn' is 404

This is valid, but since we configure the accept-language module 
to use ‘zh-CN’ it normalises $lang to the latter.  Which is good, 
but it causes the same 404 as above.

> 'zh_CN' is 200.

This is bogus (‘_’ is not valid), hence ignored, and so the site 
falls back to English 200.

> 'zh' [is 200]

Valid but the accept-language module is not clever; we need to add 
an explicit 'zh' entry for that to work:

--8<---------------cut here---------------start------------->8---
set_from_accept_language $lang en de es fr zh-CN zh en;
--8<---------------cut here---------------end--------------->8---

I expect that adding it and changing ietf-tags.scm to use "zh-CN" 
will fix both 404s, but need to check that it doesn't break 
anything else.

The other untested solution is using lowercase

--8<---------------cut here---------------start------------->8---
set_from_accept_language $lang en de es fr zh-cn zh en;
--8<---------------cut here---------------end--------------->8---

but I--assuming that even works--'m not fond of making the 
unconventional the norm.

Kind regards,

T G-R
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 4 years and 70 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.