[mod_python] Re: Re: script_name bug?

Russell Yanofsky rey4 at columbia.edu
Mon Aug 11 14:05:22 EST 2003


Gregory (Grisha) Trubetskoy wrote:
> On Sat, 9 Aug 2003, Russell Yanofsky wrote:
>
>> 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.
>
> Well, the file requested doesn't have anything to do with what
> PythonHandler specifies, e.g. in your example it will respond just the
> same with requested url of "/mptest/blahblah.py/abc/123" instead of
> "/mptest/mptest.py/abc/123". The question then becomes should
> SCRIPT_NAME be "/mptest/mptest.py" or "/mptest/blahblah.py"?

It should be /mptest/blahblah.py, because that's the .py file that the
client requested. In general, it makes sense for SCRIPT_NAME to be a URL
to the file being handled, not the to the handler. Returning a URL to the
the python handler file would be equivalent to returning a url to mod_cgi.c
in a CGI request. This doesn't make sense and wouldn't be useful.

>>> 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.
>
> It sort of does. There is a place in requestobject.c where it removes
> the trailing slash for something, then puts it back, and now I don't
> remember why it does it, but it was some rather esoteric condition
> that caused apache to infinite-recursively call some function...
> Since I don't remember what the reason was, I was always hesitant to
> remove that bit of code. It was put in years ago back in the apache
> 1.2 days, so it might be safe to remove in 2.0... I guess we can try
> it at least.

I found the code you're talking about in get_request_object() in
src/mod_python.c. I removed the special case for the trailing slash, and
everything now seems to work correctly. Patches are attached for mod_python
2.7.8 and mod_python 3.0.3. I've tested them with apache 1.3.28 and apache
2.0.47 using the SetHandler directive and AddHandler directives, and didn't
encounter any errors, infinite loops, or other unexpected behavior.

- Russ
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod_python-2.7.8.diff
Type: application/octet-stream
Size: 1229 bytes
Desc: not available
Url : http://mailman.modpython.org/pipermail/mod_python/attachments/20030811/8718dca2/mod_python-2.7.8-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod_python-3.0.3.diff
Type: application/octet-stream
Size: 1544 bytes
Desc: not available
Url : http://mailman.modpython.org/pipermail/mod_python/attachments/20030811/8718dca2/mod_python-3.0.3-0003.obj


More information about the Mod_python mailing list