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

Graham Dumpleton updated MODPYTHON-133:
---------------------------------------

Attachment: grahamd_20060226_MP133_1.diff

Attached "grahamd_20060226_MP133_1.diff" containing proposed changes.

> 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
>  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 a
s to what that really means in practice. What would make most sense is that req.serv
er.get_config() returns the mod_python configuration which is applicable to the serv
er
as a whole. Ie., outside of any configuration container such as VirtualHost, Directory, Loca
tion 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 o
bjects, if a request is made against that directory for any URL except "/xxx", I wou
ld expect that both req.config() and req.server.get_config() would not hold any refe
ren
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 w
ould 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 t
he Files directive, it is adding an entry into req.server.get_config() for P
ythonDebug.
> 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_confi
g,
>                                                  &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_confi
g,
>                                                  &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 leve
l config if "cmd->path" is NULL. This will only be the case when the directi
ve 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 object
s, but will log that as separate problem when confirmed, as exists independent of th
is issue.

[ Post a follow-up to this message ]