Solution for disabling direct access to PHP files in Apache

To directly disable access to URLs with php suffixes in rewrite rules. But later I found that the rewrite rule is called recursively. If php is directly forbidden in the rewrite rule, the rule for rewriting to the php file will also become invalid, so with the following method Apache

In the beginning, I want to directly disable access to URLs with php suffixes in rewrite rules. However, we later found that the rewrite rules were recursively called. If php is directly forbidden in the rewrite rules, the rules for rewriting to php files will also become invalid. RewriteEngineOn
The code is as follows:
RewriteRule ^ test $/test. php [L]
RewriteRule ^ test. php $0 [F, L]

Recursive calling is terrible. when accessing/test at the beginning, URL rewriting is checked once, and then matching ^ test $ is internally redirected to/test. php, however, internal redirection will also trigger URL rewriting, so check again and match to ^ test. php $ is forced to directly perform the [F] (Forbidden) operation, so it becomes the 403 error. In this case, you must determine whether the server has been redirected. At this time, a REDIRECT_URL in the server variable can be used, so I try to use this for judgment.
The code is as follows:
RewriteEngineOn
RewriteRule ^ test $/test. php [L]
RewriteCond % {REDIRECT_URL} ^ $

RewriteRule. * $0 [F, L]: As a result, the write access/test is still 403. after a slight check, it is found that % {REDIRECT_URL} in RewriteCond is always blank, which means it hurts, in this case, php cannot be directly disabled in the rewrite rules. However, it can be implemented in a less gorgeous way. It is to judge REDIRECT_URL in the PHP file. Although this method can be implemented, it feels inferior, but no better way has been found so far.
The code is as follows:
$ _ SERVER ['redirect _ url'] ordie ('foridden ');
// The text is only displayed here, and the HTTP error code needs to be output in actual use.
Echo $ _ SERVER ['redirect _ url']; // Display information of successful access
?>

The modification of this PHP code is basically no problem when it is thrown into the global reference. although it is not a perfect solution, it should at least be solved. in the future, we may find a better solution.