[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26302: Deploying the i18n’d web site
From: |
pelzflorian (Florian Pelz) |
Subject: |
bug#26302: Deploying the i18n’d web site |
Date: |
Thu, 9 Jul 2020 16:48:43 +0200 |
The trouble is that I do not have an understanding in what order nginx
tries which redirections/rewrites. An understanding is needed instead
of investigating dead ends and 3rd party nginx modules.
What I have done a while ago (the berlin patch for guix-maintenance
from my last e-mail contains this):
To redirect accesses only to HTML files I had added
(nginx-location-configuration
(uri "~ (.html|.htm)$")
(body (list "try_files $uri /$lang/$uri /$lang/$uri/index.html =404;")))
However, this does not match when nginx redirects URLs like
http://guix.gnu.org/graphics/
to the index file
http://guix.gnu.org/graphics/index.html
For this reason I had added
rewrite (.*)/$ $1/index.html;
Then it matched. But:
> > Still failing:
> >
> > http://guix.gnu.org/graphics
> >
> > http://guix.gnu.org/blog/2013/back-from-the-european-lisp-symposium
> >
> > worked before wip-i18n but stopped working. Hrm.
Previously when visiting
http://guix.gnu.org/graphics
then nginx too looked up the index file
http://guix.gnu.org/graphics/index.html
This broke. “rewrite (.*)/$ $1/index.html;” had not fixed it.
!! I do not know what to do about it.
My last change addressed this:
On Thu, Jul 09, 2020 at 03:09:57PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> > I found one problem; the nginx locations for redirecting old URLs can
> > be given a higher priority via specifying = before the location path.
>
> One thing that bit me in the past is that regex locations have higher
> precedence that other locations, IIRC.
Yes, I think this is what happened, the
(nginx-location-configuration
(uri "~ (.html|.htm)$")
(body (list "try_files $uri /$lang/$uri /$lang/$uri/index.html =404;")))
was run before the
location /news/gnu-dmd-01-released.html {
return 301 /blog/2013/gnu-dmd-01-released;
}
and therefore no return was performed.
Changing it to
location = /news/gnu-dmd-01-released.html {
return 301 /$lang/blog/2013/gnu-dmd-01-released;
}
with = in my last described attempt fixed this. Because the location
uri does not end in a slash, using = does not make a difference when
matching, but gives higher priority.
> > I cleared the browser cache, restarted nscd and tested these URLs
> > (with a changed /etc/hosts file pointing guix.gnu.org to the VM):
>
> I guess you could check with “wget -v -O /dev/null” or similar, so you
> can be sure there’s no client cache interfering.
This is a good idea. In the past I had thought things work when in
reality all was broken and it was just cached.
> If you don’t have the manual at hand, you can just make sure you’re
> getting the expected redirect, even if the end result is 404.
You are right, trying to build the manual was pointless.
> > Still failing:
> >
> > http://guix.gnu.org/graphics
> >
> > http://guix.gnu.org/blog/2013/back-from-the-european-lisp-symposium
> >
> > worked before wip-i18n but stopped working. Hrm.
> What does nginx’s error.log file say?
I can only check later, I have deleted my VM because texinfo for
building the manual consumed too much disk space.
> > http://guix.gnu.org/manual/html_node/Power-management-Services.html
>
The URL should have been
http://guix.gnu.org/manual/html_node/Power-Management-Services.html
with capital M. But the old config has the wrong URL as well I think.
I have made some wrong changes since my last mail. Will go back and
rebuild the VM from my last mail now. With what I currently have
redirection explodes
http://guix.gnu.org/manual/html_node/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/html_node
!! I think this happened too back then. I have not investigated this yet.
> I’d be happy to go ahead and deploy this so maybe let’s see and hammer
> down those remaining issues and then we can profit! Let us know how we
> can help!
>
> Thanks,
> Ludo’.
A solution for the two problems I marked with !! might be important.
Other than that, I would be very happy if first the berlin patch to
guix-maintenance and then after that the wip-i18n branch finally would
go to master.
Regards,
Florian
- bug#26302: Deploying the i18n’d web site, Christopher Baines, 2020/07/01
- bug#26302: Deploying the i18n’d web site, pelzflorian (Florian Pelz), 2020/07/05
- bug#26302: Deploying the i18n’d web site, Ludovic Courtès, 2020/07/09
- bug#26302: Deploying the i18n’d web site,
pelzflorian (Florian Pelz) <=
- bug#26302: Deploying the i18n’d web site, pelzflorian (Florian Pelz), 2020/07/10
- bug#26302: Deploying the i18n’d web site, pelzflorian (Florian Pelz), 2020/07/12
- bug#26302: Multilingual web site is on-line!, Ludovic Courtès, 2020/07/26
- bug#26302: Multilingual web site is on-line!, pelzflorian (Florian Pelz), 2020/07/26
- bug#26302: Multilingual web site is on-line!, pelzflorian (Florian Pelz), 2020/07/27
- bug#26302: Multilingual web site is on-line!, Ludovic Courtès, 2020/07/28
- bug#26302: Multilingual web site is on-line!, Julien Lepiller, 2020/07/28
- bug#26302: Multilingual web site is on-line!, pelzflorian (Florian Pelz), 2020/07/29
- bug#26302: Multilingual web site is on-line!, pelzflorian (Florian Pelz), 2020/07/29
- bug#26302: Multilingual web site is on-line!, Ludovic Courtès, 2020/07/31