quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton (JIRA)" <j...@apache.org>
Subject [jira] Work started: (MODPYTHON-171) Assignment to req.filename and POSIX style pathnames.
Date Tue, 26 Sep 2006 01:14:50 GMT
     [ http://issues.apache.org/jira/browse/MODPYTHON-171?page=all ]

Work on MODPYTHON-171 started by Graham Dumpleton.

> Assignment to req.filename and POSIX style pathnames.
> -----------------------------------------------------
>
>                 Key: MODPYTHON-171
>                 URL: http://issues.apache.org/jira/browse/MODPYTHON-171
>             Project: mod_python
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.2.8
>            Reporter: Graham Dumpleton
>         Assigned To: Graham Dumpleton
>             Fix For: 3.3
>
>
> In Apache, all the path names relating to the matched target of a request are dealt with
as POSIX style paths. That is, a forward slash is used as the directory separator even if
the platform is Win32. The only real allowance for Win32 stuff is that drive specifiers may
still occur in which case the drive letter is always converted to upper case.
> All the Apache C API functions dealing with manipulation of and specifically generation
of modified paths will by default ensure that paths are maintained in this POSIX style. To
have a path be generated in its true native form, you need to provide special flags to functions.
> When an Apache module writer works with paths, they would normally rely on the default
behaviour and so long as they use the functions provided by the Apache C API, the result will
always be consistent.
> Where would all this be a potential issue is where modules set the request_rec->filename
attribute, ie., the req.filename attribute of the mod_python request object. In a C Apache
module, as the result is always going to be in the correct form when request_rec->filename
is modified, everything still comes out okay.
> The problem in mod_python, or more perhaps when using Python, is that all the directory
manipulation routines in os.path as they exist on Win32 platform can generate paths with back
slashes in them. Further, it is often convenient to use __file__ attribute of modules in some
way, which again is going to use back slashes on Win32 platform. If the results from either
of these is assigned to req.filename, the result request_rec->filename attribute is no
longer going to be in the POSIX style form which is would normally exist if only the Apache
C APIs were used.
> One area where this causes a problem (and which isn't fixed) was described in MODPYTHON-161,
whereby setting req.filename to a path which includes back slashes instead of the required
POSIX style forward slashes can result in the wrong interpreter being selected for a subsequent
phase if the PythonInterpPerDirectory directive is being used. The case used for any drive
specifier could similarly be a problem.
> Now although Python provides os.path.normpath(), that normalises a path in the native
format. There is no function which can normalise a path and output it in the POSIX style format.
Trying to create a function in Python which does may not yield the same result as what Apache
expects.
> The actual function in Apache which can be used to normalise paths and which outputs
the POSIX style path required is apr_filepath_merge(). The question is, should this be exposed
in some way so that it is useable from mod_python, or for the req.filename case, should assignment
to req.filename automatically trigger normalisation of the path to ensure that it simply just
works all the time and isn't dependent on a user of mod_python realising they need to normalise
it first in the POSIX style to ensure their code is portable across platforms.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message