https://issues.apache.org/bugzilla/show_bug.cgi?id=40102
Bob Ionescu <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Linux |All Version|2.0.58 |2.2-HEAD --- Comment #11 from Bob Ionescu <[email protected]> 2008-12-12 10:14:45 PST --- (In reply to comment #0) > SCRIPT_NAME is passed incorrectly to PHP depending on where you place > the mod_rewrite rule. If it is placed in .htaccess or under <Directory>, the > SCRIPT_NAME is initialized correctly but when you place the same rule under > <VirtualHost> it is an empty string (or any other bogus value). [...] > The rule I'm using is: > > RewriteEngine On > RewriteCond %{SCRIPT_FILENAME} !-f > RewriteCond %{SCRIPT_FILENAME} !-d > RewriteRule ^(.*)$ /index.php/$1 In per-server context, mod_rewrite acts by default as an URI-to-filename translator. If you add the [PT] flag, mod_rewrite will copy the rewrite result back to r->uri and does not map the request to the filesystem, i.e. another URI-to-filename translator will map the request to the filesystem. In that case (if you use the PT-flag) SCRIPT_NAME seems to be set correctly. BTW: I'm wondering how your conditions will work in per-server context since w/o a URI-to-filename translation SCRIPT_FILENAME cannot contain the physical path of the request, which is needed in oder to check for existing files or dirs. See the docs bug 16402. Using apache 2.2.10 (but I think this problem is in trunk, too): - If e.g. php is used as a module Original request_uri /bar ; rewrite result /foo.php In that case (mod_php), and if there is no internal redirect, SCRIPT_NAME contains in my environment w/o the PT-flag the value of r->uri (/bar) and with the PT-flag /foo.php. ENV PATH_INFO - rewrite result /foo.php/path - is '/path' and works correct with and w/o the PT-flag. - If a directive is used which triggers an internal redirect - such as php cgi setup via the Action directive, SCRIPT_NAME will contain the value of the cgi prog. Original request_uri /bar ; rewrite result /foo.php ; the result of the Action directive is r->uri /php-script/php with path_info /bar: ScriptAlias /php-script/ "/path/to/php/" AddHandler cgi-php .php Action cgi-php /php-script/php --> SCRIPT_NAME=/php-script/php (correct with and w/o PT-flag) W/o the PT-Flag, PATH_INFO contains /bar (a subrequest for /bar will pass /foo.php to the cgi prog), REDIRECT_URL contains the original request_uri /bar, too (IMHO correct, because mod_rewrite doesn't change r->uri w/o the PT-flag, the only way Aliases can work). But that means that there is no ENV which points to the result of mod_rewrite (/foo.php). With the PT-flag set, PATH_INFO and REDIRECT_URL both contain /foo.php, which is correct. - Directly executed CGIs such as /cgi/printenv.pl with a config like (not Alias'd nor ScriptAlias'd in another way) <Directory "/var/www/cgi"> Options +ExecCGI AddHandler cgi-script .pl </Directory> r->uri: /bar ; rewrite result /cgi/printenv.pl W/o the PT-flag: regardless if PATH_INFO was specified, SCRIPT_NAME contained /bar. With the PT-flag: regardless if PATH_INFO was specified, SCRIPT_NAME contained /cgi/printenv.pl I tried to reproduce an empty SCRIPT_NAME with a rule in per-servr context, but that seems to fail in my environment, I don't know why. Instead, SCRIPT_NAME contained the unchanged r->uri of the initial request if there was no internal redirect or the PT-flag was not set. I think this is correct because mod_rewrite acts in per-server context w/o specifying the PT-flag like an Alias. To my understanding, SCRIPT_NAME represents the physical web view and if it's Alias'd it seems to me complicated if not impossible to get a physical web view. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
