[ 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
