httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 40102] SCRIPT_NAME set incorrectly with mod_rewrite
Date Fri, 12 Dec 2008 18:14:47 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=40102


Bob Ionescu <bobsiegen@googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         OS/Version|Linux                       |All
            Version|2.0.58                      |2.2-HEAD




--- Comment #11 from Bob Ionescu <bobsiegen@googlemail.com>  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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message