.conf confusion

[Rasmus Lerdorf <ra...@lerdorf.on.ca>]

Let me give this one another shot.  I'll simplify my question a lot.

Let's say I have the following in my httpd.conf

    php3userdir default    

    <VirtualHost www.domainA.com>
    php3userdir domainA
    </VirtualHost>

    <VirtualHost www.domainB.com>
    php3userdir domainB
    </VirtualHost>

There is lots more inside the two blocks, of course, and the two virtual 
hosts work fine.

However, in my module, the r->per_dir_config and r->request_config are
identical on requests to the two domains even though tracing through
things shows specifically that 3 separate config structures are created
and merged appropriately.  The subsequent call to get_module_config() then
obviously returns the same config structure which turns out to always be
the one containing the php3userdir setting for domainA.

So, what exactly triggers r->per_dir_config to be set to something, and
how might I have messed up in my module to cause it to never change?

-Rasmus

Re: .conf confusion

[Rasmus Lerdorf <ra...@lerdorf.on.ca>]

> To work around the first deficiency Rasmus had placed a call to
> php3_module_startup() in his create_server_config hook.  He didn't realise
> that create_dir_config was actually called first.  (And neither did I
> until I looked at the code, I hadn't even considered it before.) 

That's what I get for making stupid assumptions.  Many thanks to Dean for
clearing up this problem that has been making me crazy for the past 2
days.

And you can bet I will be an enthusiastic cheerleader when this API
redesign starts to take form.

-Rasmus

Re: .conf confusion

[Alexei Kosut <ak...@leland.Stanford.EDU>]

On Fri, 28 Nov 1997, Dean Gaudet wrote:

> The first is a statement of fact.  The init() phase isn't called before
> the config is parsed... in fact we're in need of a pre-config phase.  But
> that falls out of the API redesign I think -- the redesign where we
> (mostly) ditch the module structure and go for one hook which is called
> and the module must register itself for all the other phases. 

Agreed. FWIW, over winter break (another two weeks), I plan to sit down
and write up a whole lot of words explaining exactly how I think the
Apache 2.0 module API should work (except for configuration;
configuration is someone else's problem). Hopefully that will spawn some
discussion and maybe even some code ;)

BTW, do the module names "apache" and "apachen" bother anyone else? Every
time I check out a new Apache tree, I always end up with the wrong one.
Methinks we should rename them "apache1.2" and "apache1.3". That way,
there is no "apache" to get confused about, and we can make an "apache2.0"
whenever we want to.

-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
   Stanford University, Class of 2001 * Apache <http://www.apache.org> *

Re: .conf confusion

[Dean Gaudet <dg...@arctic.org>]

I helped Rasmus figure this one out... and in the process added a comment
to http_config.h:

    /* init() occurs after config parsing, but before any children are
     * forked.
     * Modules should not rely on the order in which create_server_config
     * and create_dir_config are called.
     */

The first is a statement of fact.  The init() phase isn't called before
the config is parsed... in fact we're in need of a pre-config phase.  But
that falls out of the API redesign I think -- the redesign where we
(mostly) ditch the module structure and go for one hook which is called
and the module must register itself for all the other phases. 

The second note is a bit debatable.  Here are my reasons: 

- right now it just so happens that create_dir_config phases are called
before even the server they're about to be attached to has been created. 
But I don't see any particular reason why it has to be this way. 

- the create and merge functions are supposed to be idempotent.  The same
thing should happen every time you call them with the same arguments. 

To work around the first deficiency Rasmus had placed a call to
php3_module_startup() in his create_server_config hook.  He didn't realise
that create_dir_config was actually called first.  (And neither did I
until I looked at the code, I hadn't even considered it before.) 

Dean