Website Redirect: Issues in Apache and Nginx

[iliajie]

Hello, Jamie. I suggest we fix these last issues before finally making Virtualmin 7.8 release.

The issue number 1 that manifests in both Nginx and Apache.

# 1 Setup Example:

Created redirect, even though Include sub-paths in redirect is enabled doesn't include it in redirect, i.e. on the configs (Apache and Nginx) the redirect looks like https://google.com/ rather than https://google.com/$1. We can manually set it up in the UI to redirect to https://google.com/$1 but this is not user friendly.

---

The issue number 2 is redirect loop that happens (again in both Apache and Nginx) when source URL path is set to / and the redirect happens inside of the same domain.

# 2 Setup Example:

So, if a user wants to redirect the root of the site to some dir it won't work.

Created redirect line in Apache is:

RedirectMatch ^/(?!.well-known)(.*)$ https://ubuntu22-pro.virtualmin.dev/newdir/

.. what would work in this example is:

RedirectMatch ^/(?!well-known|newdir)(.*)$ https://ubuntu22-pro.virtualmin.dev/newdir/

In case we use alternative setup, i.e. using URL at this website option instead, e.g.:

.. then the redirect loop still happens. Created code in Apache config is:

RewriteCond %{HTTPS} on
RewriteRule ^/(?!.well-known)(.*)$ https://%{HTTP_HOST}/newdir/ [R]

.. while working example is:

RewriteCond %{HTTPS} on
RewriteRule ^/(?!.well-known|newdir)(.*)$ https://%{HTTP_HOST}/newdir/ [R]

---

Issue number 3 - Explanations for Include sub-paths in redirect needs a fix, as the logic seems completely reversed, e.g.:

This first part When this is set to Yes, the sub-directory should be When this is set to No, the sub-directory. The second paragraph If No was selected in this example should be If Yes was selected in this example .. The very last paragraph However, if Yes is chosen you can use the special code $1 in the destination URL. shouldn't even exist as we should add $1 automatically and not complicate things for the user.

It has to be intuitively clear what's happening. If a user needs to refer to the documentation, then we do something wrong in the UI ..

[jcameron]

So the problem is that we don't have good support on that page for doing a redirect to another URL on the same domain uisng the same protocol, which is a little surprising! I'll need to do some work to fix this properly ...

[iliajie]

I'll need to do some work to fix this properly

Jamie, did you have chance to have a look at this?

[jcameron]

I'm still working on it - will update this bug when it's done..

[jcameron]

Ok, please check out the latest commits and let me know how it works for you now ...

[iliajie]

It doesn't solve the initial problem, i.e. redirect loop, when creating a redirect from / to /en for example (as shown in the screenshot above).

Also, I tried both options of Redirect sub-directories to. Anyway, this is how redirect is created with the first option:

RedirectMatch ^/(?!.well-known)(.*)$ /en

and this is how it looks with the second options:

RedirectMatch /(.*)$ /en

.. both create redirect loop.

[jcameron]

Oh, so what we really need is a new option to only match the specific path in the redirect.

[iliajie]

I would like it to work without any options. We should exclude the path on root, i.e. / redirects as I suggested earlier, at the start of this ticket.
And speaking of options, I would also like to drop that Redirect sub-directories to option. It's just too complicated. We need to make things work in a most straight forward and robust way, without those super confusing options. They are even confusing to me.

[jcameron]

Ok with the latest set of commits, the user can choose how sub-directory redirects work so that a redirect of / doesn't cause a loop.

[iliajie]

Alright!

I can see now that you added another option called Ignore sub-directories. It works now as intended with /. I have tested it with Apache and Nginx, it seems to work.

However, there is still one bug left in Nginx module.

If I use / as Source URL path, and URL on this website set to /php74 and option Same sub-directory under destination URL is selected, after Save, Nginx config gets this entry:

rewrite ^/(?!.well-known) /php74 redirect;

However, it is not detected by Virtualmin and you cannot set it or change it in the UI anyhow ..

[jcameron]

The latest commit to the Nginx module should fix this...

[iliajie]

Alright, great! Thanks!

Now as the final stroke, can we make Auto option for Redirect sub-directories to? For example / should always be set to a way which won't end up in redirect loop. Perhaps, there are more we can do for automatic detection? Defaults should work just fine, without asking too many questions.

Also, why we assume that if a user makes redirect for / it won't be used to renew LE? I think we should always add an exclusion for .well-known, right?

[jcameron]

Maybe we could display an error if the user creates a redirect that would cause an infinite loop?

[iliajie]

Maybe we could display an error if the user creates a redirect that would cause an infinite loop?

I think this would be a good addition as well. But still that Redirect sub-directories to? is way to complicated, even though useful and powerful.

[jcameron]

I'll add that check ..

[pixel-paul]

Hi both,

Has there been a release that includes these changes?

I'm still having problems redirecting a www.example.com URL to example.com with Nginx.

Thanks,

Paul

[jcameron]

@pixel-paul what problem are you seeing exactly?

[pixel-paul]

@iliajie suggested a method to make the www. to non-www redirect work, but this just results in a redirect loop:

virtualmin/virtualmin-nginx#6 (comment)

[pixel-paul]

I'm now running Virtualmin 7.9.0 and I still cannot get non-www to redirect to www. Note I am using Nginx

This is the redirect requirement:

https://example.com -> https://www.example.com

If I create a rule as follows:

I get a redirect loop. After it is added, I cannot see the entry in the Virtualmin Website Redirects UI, however I can see it is added in the nginx conf as:

rewrite ^/(?!.well-known) "https://www.example/$1" permanent;

I have multiple rewrite rules, so could this be an order issue? For example, Virtualmin creates the Nginx records as follows:

rewrite ^\Q/2019/xyz/beginner/\E(.*) "https://$host/xyz-beginner$1" permanent;
rewrite ^\Q/beginner/week/singles/\E(.*) "https://$host/xyz/single$1" permanent;
rewrite ^/(?!.well-known) "https://www.example.co.uk/$1" permanent;

[iliajie]

I don't think we have released Nginx plugin yet.

If you apply the latest code from virtualmin/virtualmin-nginx, does it work then?