GNU bug report logs -
#26302
[website] translations
Previous Next
Reported by: ng0 <contact.ng0 <at> cryptolab.net>
Date: Wed, 29 Mar 2017 15:41:01 UTC
Severity: normal
Done: Tobias Geerinckx-Rice <me <at> tobias.gr>
Bug is archived. No further changes may be made.
Full log
Message #194 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
This bug report was last modified 4 years and 290 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.