• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Question Remove .php and .html from url nginx

oim37

New Pleskian
Server operating system version
Centos 7
Plesk version and microupdate number
18.0.51
Hello,

Help please to make work both rules with and without (php and html) prefix from url in nginx/fpm
I add this rules in web server configuration in control panel:

if (!-e $request_filename){
rewrite ^/([^\.]+)$ /$1.php break;
}
if (!-e $request_filename){
rewrite ^/([^\.]+)$ /$1.html break;
}

But work only first. The second rule is ignored, how to combine them. Thank you.
 
Hello,

Help please to make work both rules with and without (php and html) prefix from url in nginx/fpm
I add this rules in web server configuration in control panel:

if (!-e $request_filename){
rewrite ^/([^\.]+)$ /$1.php break;
}
if (!-e $request_filename){
rewrite ^/([^\.]+)$ /$1.html break;
}

But work only first. The second rule is ignored, how to combine them. Thank you.

@oim37

There are some golden Nginx rules, two of them being :

1 - IF is EVIL : one should not use if statements, if not necessary

2 - keep it simple : this golden rule simply implies that rewrites and redirects, certainly in the same location block, are often not necessary at all!


It is clear that @scsa20 has given you a solution that is too some extent or even a high degree compliant with the aforementioned golden rules.


However, you probably can suffice by simply using the line

try_files $uri $uri.html $uri/ =404;

and you should test that first.

If that line works for requests ending with and without .html at the end, then you are ready to augment the line to

try_files $uri $uri.php $uri.html $uri/ =404;

and that one particular line should - in theory - allow you to achieve your goals.


That one particular line simply tells Nginx

- first try $uri
- then try $uri.php
- then try $uri.html ........ at this point, you have achieved your objectives already (!)
- then try $uri/ ........ just a proper addition, for the sake of certainty
- only after trying the first options, only then return the 404 code

If this particular line is not sufficient to achieve your goals and does not work with the code that Nginx is proxying for, then that code is requiring more specific Nginx config - this should (normally) not be the case!


As a final note, please note that your goals and objectives are essentially (also) dealing with requests that do not include parameters that are often quite common and/or that can be required.

That is, parameters such as .php?test=123 or .html?test=123....

If you need those parameters in order to have underlying code working properly, then the line proposed by me could still be sufficient, but you should be aware of the fact that some requests to Nginx are not including the parameters .........

............. and this is not often desirable (read: when having code that wants those parameters as input)

............. but sometimes it can be highly desirable (read: when trying to make requests more secure and less vulnerable to parameter injection)


I hope the above helps a bit!

Kind regards.....
 
Last edited:
if ($request_uri ~ ^/(.*)\.html(\?|$)) { return 302 /$1; } try_files $uri $uri.html $uri/ =404;
I tried this rule and others from popular resources on the Internet, but they do not work in the plesk. This example returns 404 without prefix
 
I tried this rule and others from popular resources on the Internet, but they do not work in the plesk. This example returns 404 without prefix
@oim37

That is because the matching group, equivalent to

(.*)

in the rule that you quoted, is not equal to the http request that you should use.

To explain in a more elaborate way, the following happens with that specific rule :

1 - if statement :

1.1 - if and ONLY IF a http request ending with .html is present, then assign the matching group (.*) WITHOUT the .html extension as a variable
1.2 - assign the variable as variable $1 and return with a 302 redirect to /$1, hence with prefix /

and there are many things that can go wrong with this :

- any http request not ending at .html will be skipped ....... for instance, requests to .php files will not be captured by the if statement
- the "/$1" can cause errors due to the prefix / ....... it can cause a double // and hence a failure
- the matching group (.*) can be matched rather unfortunately .........hence the assigned $1 variable can go wrong

2 - the redirect from the if statement is handled by the try_files directive - this is rather inefficient, also meaning that

2.1 - all issues with the if statement will also be projected to the try_files directive ........ any mistake in the if statement will cause the 404 result
2.2 - the $request_uri and $uri variables are not the same ....... so this might also cause some issues ......


In short, just rely on the try_files directive : efficient and simple to tweak.

Kind regards.....
 
Back
Top