Graham Dumpleton wrote .. > > How does req.server.get_options() differ from req.server.get_config(), > > which already exists? > > I still see what is in get_config() as special, ie., the values for > actual directives. Just don't think it is good to mix them.
Looking at this further, the distinction between req.get_config() and req.server.get_config() seems to be all broken. The code for PythonDebug is: /** ** directive_PythonDebug ** * This function called whenever PythonDebug directive * is encountered. */ static const char *directive_PythonDebug(cmd_parms *cmd, void *mconfig, int val) { const char *rc = python_directive_flag(mconfig, "PythonDebug", val, 0); if (!rc) { py_config *conf = ap_get_module_config(cmd->server->module_config, &python_module); return python_directive_flag(conf, "PythonDebug", val, 0); } return rc; } The python_directive_flag() function always returns NULL and so it adds the config value to both table objects. This means that local values for the directives in a directory/location/files/host context are going to overwrite the global ones in req.server. This code should perhaps similarly be looking to see if cmd->path is NULL. Before we decide that, we probably need to clarify what is actually mean't by the req.server.get_config() documentation. Ie., what is it supposed to return in the first place. get_config( ) Similar to req.get_config(), but returns a config pointed to by server->module_config Apache config vector. My assumption would be like in example in previous email for the PythonOption directive, is that it is the original values for the directives when defined outside of all containers. What the documentation says doesn't mean much and doesn't really say this. Thus, what do people think that req.server.get_config() is mean't to return in comparison to req.get_config(). Graham