On 20.10.2017 11:36, Ben RUBSON wrote:
On 20 Oct 2017 11:17, André Warnier (tomcat) wrote:
On 20.10.2017 10:50, Ben RUBSON wrote:
On 20 Oct 2017 10:38, André Warnier (tomcat) wrote:
On 19.10.2017 22:02, John Dunlap wrote:
To piggy back onto this question, what is the best way to do this such that the
values of
the variables are different for every virtual host? In our model, all virtual
hosts
shared
the same interpreter pool but we need to have different configuration variables
on a per
virtualhost basis. Currently, we are using PerlSetVar for this purpose.
And that seems the right way to me.
What about a startup file, as proposed by Adam, which would return John's
configuration
variables according to $ENV{'SERVER_NAME'} ? (using a switch/case for example)
Each virtualhost would then have its own configuration variables, having a uniq
startup
file for the whole server.
Would it be more performant than the PerlSetVar solution ? (doc sometimes warns
about
PerlSet* performance)
I believe that there is much more of a performance hit, when asking the server
to set up
an environment ($ENV) for sub-processes, than via the PerlSetVar mechanism.
(...)
In comparison, the mechanism involving the environment has to set up this
environment
repeatedly (at least each time a new Apache sub-process is started).
Thank you for your deeply detailed answer André !
I think mod_perl already sets $ENV by default, at least $ENV{'SERVER_NAME'} is
set.
Is there an additional cost to simply read $ENV{'SERVER-NAME'} ?
Goal would then be to set another variable according to it.
(that said, there is also $s->server_hostname() to retrieve server name)
Ok, this tells us that you are using mod_perl for more than just running perl cgi-bin
scripts, apparently.
That whole question of "environment" probably deserves a more comprehensive analysis and
description, because some of its aspects are a bit confusing (for example, what exactly is
an "Apache environment variable").
I'm just going to list some aspects here, and not really try to go in depth about them (in
part because there are many things which still puzzle me too). (Sufficiently advanced
technology cannot easily be distinguished from magic).
First, there are the values which are set in the environment of Apache httpd itself, by
whatever startup script starts Apache. (See for example, under Linux/Unix, the
/etc/Apache2/envvars script; and under Windows, the "system" and "user" variables).
Presumably, these values are duplicated whenever Apache forks itself into "children".
Second, there are values which Apache httpd sets up in the environment of the
sub-processes which it starts by itself. One example of this is when Apache httpd runs a
cgi-bin script (whether this is a perl cgi-bin script or else).
Then there are values which are set up by an Apache configuration directive "SetEnv" (or
via some other slightly more obscure mechanisms like mod_rewrite).
This is described in the Apache httpd documentation (for SetEnv/SetEnvIf) as :
"Sets an internal environment variable, which is then available to Apache HTTP Server
modules, and passed on to CGI scripts and SSI pages."
Then there are values set up when mod_perl starts up within Apache, via the "PerlRequire"
and/or "PerlSetEnv" directives which you may find (under Linux Debian/Ubuntu) in
/etc/apache2/mods-enabled/perl.conf.
Those, presumably, apply to the perl interpreter(s) which are loaded as a "side-effect" of
loading mod_perl. And they would presumably apply to anything run by mod_perl later on,
but not by non-perl "things".
A question there, is whether such values would be available to a process started by a perl
"exec" or "system" instruction run from a mod_perl handler.
Then there are the "PerlSetVar" directives, which are not really any kind of environment
values at all, but are just stored in whatever structure (at the Apache level, or only at
the mod_perl level) results from Apache (and mod_perl) parsing the Apache configuration
files. (And can be retrieved via "dir_config()").
Then there are whatever modifications you own mod_perl code may do to the content of %ENV
(and whether this is persistent or not across requests handled by the same child process;
or whether that is passed into the environment of sub-processes run via "system()" e.g.).
Then there are some perl variables which you may declare (within a handler) as "package
variables" and which (due to the fact that the perl interpreter does not restart at each
request), are kind of persistent and shared between requests (but only within the lifetime
of one Apache child). And thus, at least "delicate" to use.
Then there are values which you can store in "$r->notes()" or "$r->pnotes()", which are,
as far as I am aware, only persistent along the processing of one request.
(And in the above list, I am probably still forgetting a couple of places where you can
store things).
It is a bit confusing sometimes to try to figure out the "scope" of these
things..
I am using a bit of each of the above in my own web applications, but I must admit that
this is based more on common sense, and intuition, and some generic understanding of how
Apache and mod_perl work, rather than on any precise and comprehensive existing
documentation which one could refer to.
(Or at least, I haven't found such documentation until now).
