I was very eager to implement the new rewrite functionality in httpd.
However, I've run into an issue, and I am uncertain whether the new
behavior is CGI-compliant or not.
The app I am attempting to convert to httpd is currently built on nginx,
and the rewrite functionality it offers satisfies all of my app's needs.
But for a variety of reasons, I would prefer to use httpd. My goal is to
implement a RESTful API, which involves rewriting all requests for
"virtual" resources to target an index.php page, which uses the SlimPHP
micro framework to handle routing and all other tasks related to
servicing requests. That routing relies on the value of the REQUEST_URI
parameter to perform its work.
In httpd.conf, I have this rewrite rule:
location match "/hello/.*" {
request rewrite "/index.php"
}
while in nginx, I have this one:
try_files $uri /index.php;
location /index.php {
fastcgi_pass unix:run/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
For the URL: http://example.com/hello/fred, here are the differing
values of REQUEST_URI:
nginx: /hello/fred
httpd: /index.php
Based on the definition in the httpd.conf(5) man page, which says
$REQUEST_URI contains "the request path and optional query string", I
would have expected that the original value of REQUEST_URI would have
been preserved even after the rewrite. Otherwise, there is no way for
the target resource to know the original (pre-rewrite) URI. Unless, of
course, it was embedded within the rewritten URI as a query string by
the rewrite directive in the .conf file. But that's not very practical
if the original URI already has a query string.
Am I correct in assuming the REQUEST_URI's value should not be altered
by the rewrite operation? If the post-rewrite URI is meant to be borne
by DOCUMENT_URI, why also change the value of REQUEST_URI? This makes no
sense to me.
Many thanks in advance for any enlightenment you can provide.
