> With something like a http://foo/*> block, mod_proxy does
> the right thing ( and the simple ) of using the power of
> ap_walk_config() to handler the parsing of the contents of the block.
[...snip...]
> Reason blocks can't do that is becasue we can't let httpd try and
> parse perl code and ma
On Thu, 2003-06-12 at 02:59, Marc M. Adkins wrote:
> > > The code to implement blocks (e.g. ...) in
> > config files is
> > > pretty gnarly, too. I know it's already there for , it's
> > one of the
> > > places I looked when I was considering doing one of my own and
> > wanted to see
> > > an exam
> > The code to implement blocks (e.g. ...) in
> config files is
> > pretty gnarly, too. I know it's already there for , it's
> one of the
> > places I looked when I was considering doing one of my own and
> wanted to see
> > an example. The Apache framework is pretty strong for putting in new
>
Marc M. Adkins wrote:
However I think it is possible to make the architecture more
flexible to allow
pools sharing across specific vhosts, or even location containers (if the
scope is set to be only for the handler). e.g. something like:
#base server
# parameters
# parameters
PerlUseTiPool A
> However I think it is possible to make the architecture more
> flexible to allow
> pools sharing across specific vhosts, or even location containers (if the
> scope is set to be only for the handler). e.g. something like:
>
> #base server
>
>
> # parameters
>
>
> # parameters
>
>
>
> PerlUse
Marc M. Adkins wrote:
wrt Apache 2.0, mod_perl 2.0...
I'm not using Clone or Parent at the current time, but I was re-reading the
documentation on them for an unrelated reason and started thinking about how
they would work.
Suppose I want to set up five virtual hosts with modules A - E. Then I wa
