I am working on a site where I am using SSI to set a variable on an HTML page that gets parsed and the variable is then to be picked up by a script after a mod_rewrite rewrite. This works on my local setup, but for some reason it doesn't on the production server (both are apache 2.2.22). Here are the relevant bits:
The perl script:
my $working = ($ENV{'HTTP_my_var'} || $ENV{'REDIRECT_HTTP_my_var'}) || "NO";
print "Content-type: text/html\n\n";
print "is it working? <b>$working</b>";
relevant lines from .htaccess
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.*)$ /$1.html [L]
RewriteRule ^my_tst$ /cgi-bin/my_tst.cgi [L]
The HTML file:
<!--#set var="HTTP_my_var" value="YES" -->
<!--#include virtual="/cgi-bin/my_tst.cgi" -->
<br>
<!--#include virtual="/my_tst" -->
This is the result on my local machine:
is it working? YES
is it working? YES
But on the production server:
is it working? YES
is it working? NO
Comparing the server configs the only thing that really pops to mind is that on the production server httpd -M does not list apreq_module (shared), and the local server does not list fcgid_module (shared) (among others). Could it be due to any of these? What could be causing this strange mismatch in behavior?
In case it need mentioning, when I do a dump of %ENV, none of the REDIRECT_* variables appear in the production server in the rewrite part (the second include directive of the HTML), while they do on the local server, and the non-rewrite output of the include directive.
Edit: Adding another variable, HTTP_my_var2 which is set in the .htaccess via a SetEnv directive, has no issues, ie, the value is not trashed in the rewrite.
However, setting the variable with SetEnvIf does trigger the problem,
Edit1: Confirmed, it seems there is a strange interaction between mod_suexec, mod_rewrite and mod_include (as well as mod_setenvif). I have successfully reproduced the problem locally by running it with suexec enabled. Disabling suexec by commenting out the SuexecUserGroup line in the VirtualHost entry (and restarting the server) produces the desired results. Now to investigate possible solutions.
This might actually be a bug in apache httpd.