Let's suppose I have .htaccess file at the wwwroot of my Apache website, say, www.example.com.
I want to achieve this effect:
When the user input the link
www.example.com/dashboardin the browser, it will actually show content inwww.example.com/dashboard.phpAnd if the user directly input the link
www.example.com/dashboard.phpin the browser, it will show error.
I've tried the following .htaccess code:
RewriteEngine on
# this is to deny direct access of php files in browser
# that is, when the user input directly 'www.example.com/dashboard.php'
it will turn to error
RewriteRule \.php$ - [F,L]
# if the link the user input to the browser does not end with .php,
the code will go down ahead
# this rewrite 'www.example.com/dashboard' to 'www.example.com/dashboard.php'
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule !.*\.php$ %{REQUEST_FILENAME}.php [QSA,L,END]
However this will make www.example.com/dashboard inaccessible from the browser as well.
If I remove the RewriteRule \.php$ - [F,L] line, things are working fine but the user can still input www.example.com/dashboard.php in the browser to directly access the php page.
I'm still confused how .htaccess files are actually processed by Apache.
Is that a flow that executes the code from the beginning to the end line by line? Or something else?
UPDATE
And this gives me ERR_TOO_MANY_REDIRECTS：
RewriteEngine on
RewriteRule ^/?(.+)\.php$ /$1 [R=301]
RewriteCond %{REQUEST_FILENAME} !\.php$
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^/?(.+)$ /$1.php [END]
I'm quite confused can anyone help explain why this gives too many redirects
Indeed the apache http server processes configuration files from top to bottom. That also holds true for distributed configuration files (".htaccess"), if those are enabled ...
You can simplify your approach:
RewriteEngine on
RewriteRule \.php$ - [F,L]
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule !.*\.php$ %{REQUEST_URI}.php [END]
A variant, easier to read:
RewriteEngine on
RewriteRule \.php$ - [F,L]
RewriteCond %{REQUEST_FILENAME} !\.php$
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^/?(.+)$ /$1.php [END]
Note: there is a difference between REQUEST_FILENAME and REQUEST_URI. The QSA flag is not required here as it is the default. And L and END do not really make sense together (keep in mind: END is the new L...).
Instead of denying requests that still carry the .php file name ending you should redirect those:
RewriteEngine on
RewriteRule ^/?(.+)\.php$ /$1 [R=301]
RewriteCond %{REQUEST_FILENAME} !\.php$
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^/?(.+)$ /$1.php [END]
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a distributed configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a distributed configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using distributed configuration files (".htaccess"). Those distributed configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).