[ http://issues.apache.org/jira/brows...HON-68?page=all ]

Graham Dumpleton updated MODPYTHON-68:
--------------------------------------

Attachment: apache.py.diff

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.

> Add a readable/writable req.script_name member.
> -----------------------------------------------
>
>          Key: MODPYTHON-68
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-68
>      Project: mod_python
>         Type: New Feature
>   Components: core
>     Versions: 3.2.0
>     Reporter: Graham Dumpleton
>  Attachments: apache.py.diff
>
> 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. ;-)

[ Post a follow-up to this message ]