quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton (JIRA)" <j...@apache.org>
Subject [jira] Updated: (MODPYTHON-134) Setting PythonDebug to Off, doesn't override On setting in parent scope.
Date Sun, 05 Mar 2006 01:04:11 GMT
     [ http://issues.apache.org/jira/browse/MODPYTHON-134?page=all ]

Graham Dumpleton updated MODPYTHON-134:
---------------------------------------

    Fix Version: 3.3

> 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.7
>     Reporter: Graham Dumpleton
>     Assignee: Graham Dumpleton
>      Fix For: 3.3

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


Mime
View raw message