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)" <pelzflor...@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
