| Graham Dumpleton (JIRA) 2006-02-26, 11:33 am |
| [ http://issues.apache.org/jira/brows...ON-133?page=all ]
Work on MODPYTHON-133 started by Graham Dumpleton
> 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
>
> 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 referen
ce 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.
|