[mod_python] Re: script_name bug?

Gregory (Grisha) Trubetskoy wrote:
> Russel -
>
> Since mod_python isn't a CGI environment (and doesn't care to be one
> either), the definition of SCRIPT_NAME is rather blurry.

It might be blurry when a directory handler is used, but it's not at all
blurry in
this case, where mod_python is acting as a handler for requests for
.py files. SCRIPT_NAME should simply point to the .py file that has
been requested.

> In CGI it is meant to refer to the script which is executed as a
> separate process - in mod_python there is no separate process, and
> the file containing the code isn't located by the web server, but
> rather follows the Python sys.path search rules.

The CGI specification may define SCRIPT_NAME in terms of processes and
script files, but the SCRIPT_NAME is not just used for CGI. It's used in PHP
and ASP and other web interfaces, and is also useful in mod_python when
mod_python doesn't mangle it.

> I don't think it would be right to tinker with what req.subprocess_env
> contains - it should return whatever apache put there, uncensored, so
> to that degree it's not a bug as far as I am concerned.

But, AFAICT, it is tinkering with the value. Under the apache CGI
environment, the SCRIPT_NAME value is just the portion of the URL pointing
at the script being handled, but in mod_python when the request ends in a
slash, the value has extra stuff appended. So mod_python must be doing
something that mod_cgi is not.

> P.S. If you look at build_cgi_env() in apache.py, it seems to adress
> this issue.

That code does sort of address this issue, but in an indirect way. Instead
of using the mangled SCRIPT_NAME value in subprocess_env, it recomputes it
using req.uri and req.path_info. This is similar to the workaround I used in
my last posting, and it also will fail in the presence of double slashes in
PATH_INFO. It would be better to fix this bug instead of using these
unreliable workarounds.

- Russ