[ http://issues.apache.org/jira/browse/MODPYTHON-133?page=all ]
Graham Dumpleton updated MODPYTHON-133:
---------------------------------------
Fix Version: 3.3
> req.server.get_config() table object populated wrongly.
> -------------------------------------------------------
>
> Key: MODPYTHON-133
> URL: http://issues.apache.org/jira/browse/MODPYTHON-133
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2
> Reporter: Graham Dumpleton
> Assignee: Graham Dumpleton
> Fix For: 3.3
> Attachments: grahamd_20060226_MP133_1.diff
>
> Documentation states for req.server.get_config():
> req.server.get_config()
> Similar to req.get_config(), but returns a config pointed to by
> server->module_config Apache config vector.
> where req.get_config() documentation states:
> req.get_config()
> Returns a reference to the table object containing the mod_python
> configuration in effect for this request except for Python*Handler and
> PythonOption (The latter can be obtained via req.get_options(). The
> table has directives as keys, and their values, if any, as values.
> The documentation for req.server.get_config() doesn't actually tell you
> anything as to what that really means in practice. What would make most sense
> is that req.server.get_config() returns the mod_python configuration which is
> applicable to the server as a whole. Ie., outside of any configuration
> container such as VirtualHost, Directory, Location or Files. Even if one
> assumes that that is what it is mean't to do, that isn't what it actually
> does.
> Consider .htaccess file containing:
> SetHandler mod_python
> PythonHandler handler
> <Files xxx>
> PythonDebug On
> </Files>
> Where the handler file contains:
> from mod_python import apache
> def handler(req):
> req.content_type = 'text/plain'
> req.write('req.get_config()='+str(req.get_config())+'\n')
> req.write('req.server.get_config()='+str(req.server.get_config())+'\n')
> return apache.OK
> Noting that PythonDebug is off by default and when off it isn't put in the
> table objects, if a request is made against that directory for any URL except
> "/xxx", I would expect that both req.config() and req.server.get_config()
> would not hold any reference to PythonDebug. Ie., expect to see:
> req.get_config()={}
> req.server.get_config()={}
> This isn't what you get though. Instead you get:
> req.get_config()={}
> req.server.get_config()={'PythonDebug': '1'}
> The req.get_config() is correct, but not req.server.get_config().
> If the "/xxx" is accessed, you don't get what you expect either. Whereas
> would expect:
> req.get_config()={'PythonDebug': '1'}
> req.server.get_config()={}
> get instead:
> req.get_config()={'PythonDebug': '1'}
> req.server.get_config()={'PythonDebug': '1'}
> The problem is that when merely processing the Apache configuration, for the
> Files directive, it is adding an entry into req.server.get_config() for
> PythonDebug.
> The code causing this is:
> static const char *directive_PythonDebug(cmd_parms *cmd, void *mconfig,
> int val) {
> const char *rc = python_directive_flag(mconfig, "PythonDebug", val, 0);
> if (!rc) {
> py_config *conf = ap_get_module_config(cmd->server->module_config,
> &python_module);
> return python_directive_flag(conf, "PythonDebug", val, 0);
> }
> return rc;
> }
> If this code is changed to:
> static const char *directive_PythonDebug(cmd_parms *cmd, void *mconfig,
> int val) {
> const char *rc = python_directive_flag(mconfig, "PythonDebug", val, 0);
> if (!cmd->path) {
> py_config *conf = ap_get_module_config(cmd->server->module_config,
> &python_module);
> return python_directive_flag(conf, "PythonDebug", val, 0);
> }
> return rc;
> }
> it works in the way that would seem to make sense.
> The change here is that the configuration is only added to the server level
> config if "cmd->path" is NULL. This will only be the case when the directive
> is used outside of any configuration container.
> Note that all the directive functions need to change and not just this one.
> Ie., search all of mod_python.c and change any instance of "if (!rc)" to "if
> (!cmd->path)" for these directive functions.
> There is actually another problem with merging of these flags in the config
> objects, but will log that as separate problem when confirmed, as exists
> independent of this issue.
--
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
