[jira] Assigned: (MODPYTHON-134) Setting PythonDebug to Off, doesn't override On setting in parent scope.

["Graham Dumpleton (JIRA)" <ji...@apache.org>]

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

Graham Dumpleton reassigned MODPYTHON-134:
------------------------------------------

    Assign To: 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 configuration for any requests landing in the directory the .htaccess file is for. 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 PythonDebug being Off.
> That doesn't work either.
> The problem comes about from the fact that each container context has a separate table object. All these table objects are merged together, with values in more specific containers pertaining to a request, overriding those from a parent container. Unfortunately, in mod_python 3.X (wasn't the case in 2.7), the python_directive_flag() function was 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 PythonAutoReload not working as documented in MODPYTHON-106. Back in mod_python 2.7, setting the value to "0" is what always occured, it didn't use to use unset:
>   apr_table_unset(conf->directives, key);
> Since the unset instead of adding in "0" was used, there was no table object 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 changed.  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 (PythonInterpPerDirectory,
>   PythonInterpPerDirective) is set to on when it isn't, thus causing that to stop working
>   correctly. 
> Thus code associated with PythonInterpPerDirectory and PythonInterpPerDirective 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.

-- 
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