Re: why open_logs/post_config hooks are run only for the main server?

["William A. Rowe, Jr." <wr...@apache.org>]

At 04:47 PM 12/22/2003, Stas Bekman wrote:

>I'm not sure this is a good idea to run it on the main host. If it was we could just as well run post_config for each vhost as well. 

No, you missed my earlier point.  post_config is a run-once.  host_init is the
run-each you requested.

>The problem is that if that hook is configurable via a directive this directive will be inherited by all vhosts if defined in the main server (via the usual merge rules). And you end up running it for each vhost even if you didn't intend to.

Stop...  hooks aren't configured by directives as you imply.

The directive is processed in some phase, but the hook runs against all.  That's
why we wondered why you couldn't loop it, although I had no objection to simply
invoking this hook.

As a matter of fact, you give me an idea I'll discuss at the end.

As far as inheritance, hosts *should* inherit global settings unless the author
goes to great pain to *document* and then provide such behavior.  Intuitively
folks presume inheritance within httpd.conf from global into each local conf.

>So if adding this hook at all, it should be invoked *only* on vhosts, and never on the main server [...] and then vhost_init is the right choice.

No... the default server is still a server.  But you make an interesting point, that
certain percolation occurs in the post config.  I suppose I would want that to
happen before my handlers dealt with the per-vhost settings, and I would not
want the changes I make to that global server to percolate any longer in the
host_init phase.  So running the post config, then the host init phases makes
sense for that paradigm.

If we invoke this hook for vhosts, it must be invoked on the main host.

What the handlers do should be affected by the per-host directives, and not
the other way around (handlers shouldn't be invoked because of per-host
directives.)

But let's imagine a scenario of dynamic vhosts, al la htaccess.  It would actually
be quite cool in one thread to create such a dynamic host (propagate from some
given vhost for example.)  This host init hook would still be run against the thread
specific dynamic server record.  We could get away with some really cool things
that way :)  Discuss ...

Bill 

Re: why open_logs/post_config hooks are run only for the main server?

[Stas Bekman <st...@stason.org>]

William A. Rowe, Jr. wrote:
> At 04:47 PM 12/22/2003, Stas Bekman wrote:
> 
> 
>> I'm not sure this is a good idea to run it on the main host. If it was we
>> could just as well run post_config for each vhost as well.
> 
> 
> No, you missed my earlier point.  post_config is a run-once.  host_init is
> the run-each you requested.

but since you can iterate over vhosts from post_config, you don't really need 
a special hook. As if there was one.

>> The problem is that if that hook is configurable via a directive this
>> directive will be inherited by all vhosts if defined in the main server
>> (via the usual merge rules). And you end up running it for each vhost
>> even if you didn't intend to.
> 
> 
> Stop...  hooks aren't configured by directives as you imply.

They are in mod_perl, most of them. So that users can write they own callbacks.

> The directive is processed in some phase, but the hook runs against all.
> That's why we wondered why you couldn't loop it, although I had no
> objection to simply invoking this hook.

I wasn't sure I needed to loop. But now it seems to be a fine idea and no 
extra hook is needed.

> As a matter of fact, you give me an idea I'll discuss at the end.
> 
> As far as inheritance, hosts *should* inherit global settings unless the
> author goes to great pain to *document* and then provide such behavior.
> Intuitively folks presume inheritance within httpd.conf from global into
> each local conf.

That's correct.

>> So if adding this hook at all, it should be invoked *only* on vhosts, and
>> never on the main server [...] and then vhost_init is the right choice.
> 
> 
> No... the default server is still a server.  But you make an interesting
> point, that certain percolation occurs in the post config.  I suppose I
> would want that to happen before my handlers dealt with the per-vhost
> settings, and I would not want the changes I make to that global server to
> percolate any longer in the host_init phase.  So running the post config,
> then the host init phases makes sense for that paradigm.
> 
> If we invoke this hook for vhosts, it must be invoked on the main host.
> 
> What the handlers do should be affected by the per-host directives, and not
>  the other way around (handlers shouldn't be invoked because of per-host 
> directives.)

That's fine. I was talking about a different situation as you may have 
understood from my comments, which is not normal under plain Apache. I'm 
totally fine with the current behavior.

> But let's imagine a scenario of dynamic vhosts, al la htaccess.  It would
> actually be quite cool in one thread to create such a dynamic host
> (propagate from some given vhost for example.)  This host init hook would
> still be run against the thread specific dynamic server record.  We could
> get away with some really cool things that way :)  Discuss ...


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: why open_logs/post_config hooks are run only for the main server?

[Geoffrey Young <ge...@modperlcookbook.org>]

> No... the default server is still a server.  But you make an interesting point, that
> certain percolation occurs in the post config.  I suppose I would want that to
> happen before my handlers dealt with the per-vhost settings, and I would not
> want the changes I make to that global server to percolate any longer in the
> host_init phase.  So running the post config, then the host init phases makes
> sense for that paradigm.

cool.  just to keep up, new patches attached.

> But let's imagine a scenario of dynamic vhosts, al la htaccess.  It would actually
> be quite cool in one thread to create such a dynamic host (propagate from some
> given vhost for example.)  This host init hook would still be run against the thread
> specific dynamic server record.  We could get away with some really cool things
> that way :)  Discuss ...

you'd need a way to direct requests directly to that specific thread,
though, right?  anyway, what kind of cool things?  I can see some advantage
to this oven in prefork, where you might want to dedicate a pool of children
to specific clients, but I don't really see the threaded advantages.  but I
generally don't get threaded environments anyway :)

--Geoff