Graham Dumpleton wrote:
Graham Dumpleton wrote ..

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.


Thus, FWIW, I get what I would expect when I change the code to:

/**
 ** 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 (!cmd->path) {
        py_config *conf = ap_get_module_config(cmd->server->module_config,
                                               &python_module);
return python_directive_flag(conf, "PythonDebug", val, 0);
    }
    return rc;
}

It isn't just this directive processor though, all of them should have:

  if (!rc) {

changed to:

  if (!cmd->path) {

The actual return values from the function are really meaningless as
they are always NULL.


The ap_check_cmd_context function may also be of interest.
http://docx.webperf.org/group__ap__check__cmd__context.html

For example, lets say we wanted to disallow the use of PythonDebug in <VirtualHost>

  const char *err;
    if ((err = ap_check_cmd_context(cmd, NOT_IN_VIRTUALHOST))) {
       return err;
    } else {
      /* do some processing */
    }

Jim

Reply via email to