Add a readable/writable req.script_name member.

• Key: MODPYTHON-68
• Type: New Feature
• Status: Closed
• Resolution: Won't Fix
• Priority: Major
• Assignee: Unassigned
• Reporter: Graham Dumpleton
• Component/s: core
• Affects Version/s: 3.2.7

Description

The term SCRIPT_NAME in web servers is used to identify that part of a
URI which identifies the script handling the request. Within the URI,
the SCRIPT_NAME component would be followed by the PATH_INFO component,
the latter being potentially an empty string.

In mod_python, the value of SCRIPT_NAME could be obtained in a few
different ways. These are:

1. Obtain it as req.subprocess_env["SCRIPT_NAME"] after having first
called req.add_common_vars().

2. Obtain it as apache.build_cgi_env(req)["SCRIPT_NAME"]. This
internally calls req.add_common_vars() but then ignores "SCRIPT_NAME"
value from req.subprocess_env and instead tries to calculate it as per
(3) below yeilding a different result to (1) in some cases.

3. Attempt to derive it req.uri using code which is based upon something
like 'req.uri[:-len(req.path_info)]'. If req.path_info is empty, then the result
should be the same as req.uri.

All three methods actually yield incorrect results in certain
circumstances, with the fact that it occurs in (1) suggesting an
underlying Apache bug.

The problem area is where there are multiple successive occurrences of
'/' appearing in the part of the URI which is used to determine the
PATH_INFO value.

Looking at some examples for each case we get:

req.uri = /~grahamd/handler/mptest.py
req.path_info =
PATH_INFO = None
SCRIPT_NAME (1) = /~grahamd/handler/mptest.py
SCRIPT_NAME (2) = /~grahamd/handler/mptest.py
SCRIPT_NAME (3) = /~grahamd/handler/mptest.py

req.uri = /~grahamd/handler/mptest.py/
req.path_info = /
PATH_INFO = /
SCRIPT_NAME (1) = /~grahamd/handler/mptest.py
SCRIPT_NAME (2) = /~grahamd/handler/mptest.py
SCRIPT_NAME (3) = /~grahamd/handler/mptest.py

req.uri = /~grahamd/handler/mptest.py//
req.path_info = /
PATH_INFO = /
SCRIPT_NAME (1) = /~grahamd/handler/mptest.py
SCRIPT_NAME (2) = /~grahamd/handler/mptest.py/
SCRIPT_NAME (3) = /~grahamd/handler/mptest.py/

req.uri = /~grahamd/handler/mptest.py/a
req.path_info = /a
PATH_INFO = /a
SCRIPT_NAME (1) = /~grahamd/handler/mptest.py
SCRIPT_NAME (2) = /~grahamd/handler/mptest.py
SCRIPT_NAME (3) = /~grahamd/handler/mptest.py

req.uri = /~grahamd/handler/mptest.py/a/b
req.path_info = /a/b
PATH_INFO = /a/b
SCRIPT_NAME (1) = /~grahamd/handler/mptest.py
SCRIPT_NAME (2) = /~grahamd/handler/mptest.py
SCRIPT_NAME (3) = /~grahamd/handler/mptest.py

req.uri = /~grahamd/handler/mptest.py/a//b
req.path_info = /a/b
PATH_INFO = /a/b
SCRIPT_NAME (1) = /~grahamd/handler/mptest.py/a
SCRIPT_NAME (2) = /~grahamd/handler/mptest.py/
SCRIPT_NAME (3) = /~grahamd/handler/mptest.py/

req.uri = /~grahamd/handler/mptest.py/a///b
req.path_info = /a/b
PATH_INFO = /a/b
SCRIPT_NAME (1) = /~grahamd/handler/mptest.py/a/
SCRIPT_NAME (2) = /~grahamd/handler/mptest.py/a
SCRIPT_NAME (3) = /~grahamd/handler/mptest.py/a

req.uri = /~grahamd/handler/mptest.py/a///b//c
req.path_info = /a/b/c
PATH_INFO = /a/b/c
SCRIPT_NAME (1) = /~grahamd/handler/mptest.py/a///b
SCRIPT_NAME (2) = /~grahamd/handler/mptest.py/a/
SCRIPT_NAME (3) = /~grahamd/handler/mptest.py/a/

All very strange and not what one would expect.

Ignoring the strange results, the first point of creating the tracker
item is to propose that a new member be added to the request object
referred to as "req.script_name". This new member should be both
readable and writable.

The argument for adding "script_name" is similar to that for making
"path_info" writable as described in MODPYTHON-67. That is, it would
make the task of writing a middleware stack specifically for mod_python
but in a similar style to WSGI a slightly simpler task.

In adding "script_name", it is perhaps suggested that its initial value be
somewhat saner than as shown in the results above. More along the lines
of:

req.uri = /~grahamd/handler/mptest.py//
req.path_info = /
script_name=/~grahamd/handler/mptest.py

req.uri = /~grahamd/handler/mptest.py/a//b
req.path_info = /a/b
script_name=/~grahamd/handler/mptest.py

req.uri = /~grahamd/handler/mptest.py/a///b
req.path_info = /a/b
script_name=/~grahamd/handler/mptest.py

req.uri = /~grahamd/handler/mptest.py/a//b//c
req.path_info = /a/b/c
script_name=/~grahamd/handler/mptest.py

It should perhaps also normalise the path to eliminate duplicate
instances of '/' in the URI appearing before the PATH_INFO component.

req.uri = /~grahamd/handler////mptest.py/a/b/c
req.path_info = /a/b/c
PATH_INFO = /a/b/c
SCRIPT_NAME (1) = /~grahamd/handler////mptest.py
SCRIPT_NAME (2) = /~grahamd/handler////mptest.py
SCRIPT_NAME (3) = /~grahamd/handler////mptest.py
script_name=/~grahamd/handler/mptest.py

In respect of the problems with (1) and (2), one probably should not do
anything about (1) as that is generated by Apache. As to (2), since it
is mean't to parallel what Apache provides, maybe it should just pass
through the "SCRIPT_NAME" from "req.subprocess_env". Not sure why the
latter ignores the value supplied by Apache and determines it itself, thus
yielding a different value in cases as shown.

And yes I do have an agenda by pushing these req.path_info and
req.script_name changes. My work should benefit mod_python though,
so don't be scared. ;-)

Comments

[Graham Dumpleton]

Patch to apache.py which adds req.script_name member.

Since access is needed to posixpath module to normalise path,
seemed easier to do it here than try and embed it inside of the
requestobject.c code.

[Graham Dumpleton]

I add my own -1 to this patch to add req.script_name. It is just as easy to stick it in a root level handler middleware wrapper. I would still like req.path_info to be writable though as it becomes impossible to write middleware wrappers that incorporate existing mod_python.publisher and mod_python.psp code otherwise. :-)

The information here is still pertinent in pointing out that existing ways in which SCRIPT_NAME is determined is wrong in some situations.

[Graham Dumpleton]

Idea of adding req.script_name was withdrawn, so close off issue.