httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Wortham" <>
Subject Re: Examining per_dir_config for a module
Date Thu, 12 Apr 2007 17:38:12 GMT
    I am dealing with the same issue (debugging dir_cfg data) today in fact,
so you may be able to benefit from my debugging method.

    From my experience: you are correct about the timing involved in the
creation of dir_cfgs (they are created and merged at the beginning of a
If you log the data at the end of the merge function, you will see the data
in the dir_cfg as it is given to the request handler.

   My suggestion to you:
(1) Add a string to your dir_cfg to store the regex (if any) which a
directory/location/etc. should match (a descriptor/identifier string).  You
can get this value from the second parameter in the
"my_create_dir_cfg(apr_pool_t*, char*)" function.
(2) Log all of your dir_cfg data at the beginning and end of the
merge_dir_cfg function.
(3) Create a webpage that will request elements (images, javascript, css, or
embed elements) from many of your directories (triggering many of your
directories to respond to requests).

   I used one central logfile for my module's merge-logging, but you can do
something creative and split it based on directory/location/vhost/etc (maybe
append a hash of the string to match to the end of the logfile name, and
make sure to account for multiple dir_cfgs with NULL descriptor/identifier


On 4/12/07, Joe Lewis <> wrote:
> David Wortham wrote:
> > SRP,
> >    If I am correct, that will work if you only need to look at only
> > server/vhost cfg structures (won't work for directory, location,
> > files, or
> > .htaccess directives).
> I believe that is correct.  When I created a logging module to check
> which hooks were being called and when, I found that per-directory
> configurations are created at request-time, not at initialization time,
> and are subsequently removed.  AFAIK, the pools are trashed as soon as
> the request is complete, meaning a global overview of what directives
> are used in per-directory is just not unavailable.
> If it is absolutely required, then per-directory functions that set
> values from directives can be implemented that duplicate the
> per-directory configuration on the global module config.  However, that
> can get very ugly very quickly.  It might be easier to just have the
> same function insert/update the directive and the corresponding
> directory that it was found in into a database, and then search that if
> necessary.  Again, it requires a custom function to set the field from
> the directives (command_rec* table sets this function in per-directory
> configs via ap_set_*_slot functions).
> Joe
> --
> Joseph Lewis <>
> "Divide the fire, and you will sooner put it out." - Publius Syrus

David Wortham
Senior Web Applications Developer
Unspam Technologies, Inc.
1901 Prospector Dr. #30
Park City, UT 84060
(435) 513-0672

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message