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