https://website.com/api/somefolder/test/512/31
Should rewrite to:
https://website.com/api/somefolder/test.php?param1=512¶m2=31
and
https://website.com/api/somefolder/anotherfolder/hello/yo/44
Should rewrite to:
https://website.com/api/somefolder/anotherfolder/hello.php?param1=yo¶m2=44
RewriteEngine On
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule !.*.php$ %{REQUEST_FILENAME}.php?param1=$1¶m2=$2 [QSA,L]
The rewrite works but $1 and $2 are empty. Any idea why?
My htaccess file is located in the api directory.
2
Answers
Sure, the two parameters are empty since you never full them with content…
Take a look at that example instead:
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).
You may use this rule in
api/.htaccess
withOptions -MultiViews
at the top that turns off content negotiation service of Apache: