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

Work on MODPYTHON-134 started by Graham Dumpleton

> Setting PythonDebug to Off, doesn't override On setting in parent scope.
> ------------------------------------------------------------------------
>
>          Key: MODPYTHON-134
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-134
>      Project: mod_python
>         Type: Bug
>   Components: core
>     Versions: 3.2
>     Reporter: Graham Dumpleton
>     Assignee: Graham Dumpleton

>
> If you put:
>   PythonDebug On
> in your main Apache configuration file, one would assume that you can then
 in a .htaccess file say:
>   PythonDebug Off
> and that in the .htaccess file would override that in the main Apache conf
iguration for any requests landing in the directory the .htaccess file is fo
r. That is, that PythonDebug would be Off.
> You might assume this, but it doesn't work.
> Similarly, even within a .htaccess file, if you have:
>   PythonDebug On
>   <Files xxx>
>   PythonDebug Off
>   </Files>
> one would assume that accessing "/xxx" in that directory would see PythonD
ebug being Off.
> That doesn't work either.
> The problem comes about from the fact that each container context has a separate t
able object. All these table objects are merged together, with values in more specif
ic containers pertaining to a request, overriding those from a parent container. Unf
ort
unately, in mod_python 3.X (wasn't the case in 2.7), the python_directive_flag() function wa
s added and coded to not put an entry in the table object for the Off case.
> The current code for the python_directive_flag() function is:
> static const char *python_directive_flag(void * mconfig,
>                                          char *key, int val, int set)
> {
>     py_config *conf;
>     conf = (py_config *) mconfig;
>     if (val) {
>         apr_table_set(conf->directives, key, "1");
>     }
>     else {
>         if (set) {
>             apr_table_set(conf->directives, key, "0");
>         }
>         else {
>             apr_table_unset(conf->directives, key);
>         }
>     }
>     return NULL;
> }
> Note that the line section:
>         if (set) {
>             apr_table_set(conf->directives, key, "0");
>         }
> was only added back in mod_python 3.2.7 specifically to fix problem with P
ythonAutoReload not working as documented in MODPYTHON-106. Back in mod_pyth
on 2.7, setting the value to "0" is what always occured, it didn't use to us
e unset:
>   apr_table_unset(conf->directives, key);
> Since the unset instead of adding in "0" was used, there was no table obje
ct value for Off and so it can't override On in a parent container and so it
 still inherits the On value. Thus why it can't be turned Off once On.
> Seems the only solution is to go back to using:
> static const char *python_directive_flag(void * mconfig,
>                                          char *key, int val)
> {
>     py_config *conf;
>     conf = (py_config *) mconfig;
>     if (val) {
>         apr_table_set(conf->directives, key, "1");
>     }
>     else {
>         apr_table_set(conf->directives, key, "0");
>     }
>     return NULL;
> }
> But to do this, other parts of mod_python.c are going to have to be change
d.  Specifically MODPYTHON-106 identified:
>   One can't just always set it to "0", as other code in mod_python.c uses 
the fact
>   that an option exists to mean it is set. Ie., it doesn't check the value
, thus setting
>   it to "0" will cause that code to think the option used in that case (Py
thonInterpPerDirectory,
>   PythonInterpPerDirective) is set to on when it isn't, thus causing that 
to stop working
>   correctly.
> Thus code associated with PythonInterpPerDirectory and PythonInterpPerDire
ctive is going to have to be changed to check the value in the table object 
and see if it is "1". There seems no other choice now.
> Note that any user code which also merely checks for the existing of the directive
, such as PythonDebug, without testing the value would also need to be changed as it
 will potentially not work properly.

[ Post a follow-up to this message ]