[ http://issues.apache.org/jira/browse/MODPYTHON-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 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
