bug-guix
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]