[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46807: [website] return 404 with HTTP header 'Accept-Language: zh-CN
From: |
Tobias Geerinckx-Rice |
Subject: |
bug#46807: [website] return 404 with HTTP header 'Accept-Language: zh-CN, zh' |
Date: |
Sat, 27 Feb 2021 13:31:40 +0100 |
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@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
Description: PGP signature