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

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

        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().


Reply via email to