Question Remove .php and .html from url nginx

[oim37]

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.

 

[scsa20]

From NGINX remove .html extension

    if ($request_uri ~ ^/(.*)\.html(\?|$)) {
        return 302 /$1;
    }
    try_files $uri $uri.html $uri/ =404;

 

[trialotto]

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.....

 

[oim37]

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

 

[trialotto]

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.....