i’m using an htaccess script trying to remove the .php testing the .htaccess on a testing server it runs fine, but on the live server that is a different host it trys rewriting the file based on the absolute path and the rewrite fails
here is the htaccess:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^(.*)$ $1.php
this is taking a url like this http://www.example.com/services
and trying to point it to /n/c/example.com/public/service.php
I know the {REQUEST_FILENAME} is suppose to be pulling the full local system path, but i don’t understand why it’s not finding the file. i know very little about htaccess and mod_rewriting so i’m not really sure what I should try to make it base everything off of just the url path, or if there is a better solution. I’m really open to suggestions.
Any help would be greatly appreciated.
Thanks
Use
RewriteRule .* %{REQUEST_URI}.php [L]It is hard to tell why your rule did not worked for you by having so little info about your Apache setup and any other rewrite rules that you may have.
Quite possible that the
[L]flag did the trick for you — you may have other rewrite rules that were rewriting this URL further, producing incorrect result in the end. I don’t think that%{REQUEST_URI}did such a big job on its own, unless you have some symbolic links / aliases or even some transparent proxy in use which could make a difference.Keep in mind, that the rules you have shown in your question cannot generate this sort of URL to be visible in browser’s address bar (
example.com//service.php/) — it has to be a redirect (3xx code) involved .. which suggests that you have other rules somewhere.Most likely it is a combination of your Apache specific settings & combined rewrite rules logic (where the
Lflag can make a big difference depending on those other rules).The only way to give more precise answer will be enabling rewrite debugging and analyzing how rewrite was executed and what was involved.