Mailing List Archive

On Mon, 8 May 1995, Robert S. Thau wrote:
> My suggestion is to combine these to features into a new directive for
> httpd.conf;
> ImportEnv <variable-name>
...
> Hmmm... ImportEnv is probably more convenient for things like TZ, but
> the EIT-extended SetEnv directive is probably better for most uses (in
> particular, for script config vars) --- it lets you put both variable
> and value in the config files, rather than having to name the variable
> in the config files, and set the value in (I guess) a shell script
> which starts up the server with a customized environment.

Right. I'd vote for both, config file inflation be damned :)

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Date: Mon, 8 May 95 16:17 BST
From: drtr@ast.cam.ac.uk (David Robinson)

I have also heard of suggestions to allow the setting of environment
variables in the config files.

My suggestion is to combine these to features into a new directive for
httpd.conf;
ImportEnv <variable-name>

which would allow named variables in the httpd environment to be passed
to CGI scripts. e.g.
ImportEnv TZ
ImportEnv X_SCRIPT_ROOT

David.

Hmmm... ImportEnv is probably more convenient for things like TZ, but
the EIT-extended SetEnv directive is probably better for most uses (in
particular, for script config vars) --- it lets you put both variable
and value in the config files, rather than having to name the variable
in the config files, and set the value in (I guess) a shell script
which starts up the server with a customized environment.

rst

Last time, Brian Behlendorf uttered the following other thing:
>
> On Mon, 8 May 1995, Robert S. Thau wrote:
> > My suggestion is to combine these to features into a new directive for
> > httpd.conf;
> > ImportEnv <variable-name>
> ...
> > Hmmm... ImportEnv is probably more convenient for things like TZ, but
> > the EIT-extended SetEnv directive is probably better for most uses (in
> > particular, for script config vars) --- it lets you put both variable
> > and value in the config files, rather than having to name the variable
> > in the config files, and set the value in (I guess) a shell script
> > which starts up the server with a customized environment.
>
> Right. I'd vote for both, config file inflation be damned :)

Sounds good to me. I've had enough problems with TZ to add them both
to 1.5 (the SetEnv and ImportEnv that is)

BTW, httpd 1.4 does attempt to pass TZ. It just seems that most of the
environment variables don't last until CGI scripts are exec'd. I don't
know why this is. I know some systems (like SCO) seems to remove them
after the detach() (hence the CALL_TZSET define in 1.4)

Brandon
--
Brandon Long (N9WUC) "I think, therefore, I am confused." -- RAW
Computer Engineering Run Linux 1.1.xxx It's that Easy.
University of Illinois blong@uiuc.edu http://www.uiuc.edu/ph/www/blong
Don't worry, these aren't even my views.

>Hmmm... ImportEnv is probably more convenient for things like TZ, but
>the EIT-extended SetEnv directive is probably better for most uses (in
>particular, for script config vars) --- it lets you put both variable
>and value in the config files, rather than having to name the variable
>in the config files, and set the value in (I guess) a shell script
>which starts up the server with a customized environment.

Sure. But the implementation of setting of environment variables in the config
files requires more thought than the implementation of simply importing
varaibles.

i.e.
Should one be allowed to set environment variables in .htaccess files,
or in server-side include scripts? If so, I think there should be a
restriction on the name of the variables that can be set in that case, e.g.
they must all begin X_USER_.
This restriction would not apply to the use of SetEnv in srm.conf.

Whereas I would imagine ImportEnv only being used in httpd.conf.

David.

Date: Wed, 10 May 95 16:53 BST
From: drtr@ast.cam.ac.uk (David Robinson)

Sure. But the implementation of setting of environment variables in
the config files requires more thought than the implementation of
simply importing varaibles.

Hmmm... the interesting issue you raise below all have to do with
setting environment variables *outside* the config files (in .htaccess
files, through SSI, etc.)... and imports of environment variables in
those places might be as troublesome as outright sets (particularly if
the daemon was originally started from someone's command line, and
might have interesting stuff lying around to be imported).

Are SetEnvs in srm.conf (IMHO, the right place for it --- looking
forward to a day when virtual hosts can have their own full srm.conf
and access.conf files) particularly troublesome?

rst

>Hmmm... the interesting issue you raise below all have to do with
>setting environment variables *outside* the config files (in .htaccess
>files, through SSI, etc.)... and imports of environment variables in
>those places might be as troublesome as outright sets (particularly if
>the daemon was originally started from someone's command line, and
>might have interesting stuff lying around to be imported).
>
>Are SetEnvs in srm.conf (IMHO, the right place for it --- looking
>forward to a day when virtual hosts can have their own full srm.conf
>and access.conf files) particularly troublesome?

It's really just a matter of trying to do the Right Thing Right Now.

In some ways, I see a stronger case for SetEnv in .htaccess or .shtml files
than in srm.conf. The most common use (that I have heard argued) is for
passing configuration information to CGI scripts, to avoid them containing
hard-coded data.

For example, the receipient email address for an e-mail script, or the
root of a database tree for a dbase CGI script.

Also, there might be conflicts between the variables that different CGI
scripts needed.

I don't think it is appropriate for ImportEnv to be set anywhere except
httpd.conf; it should be primarily concerned with the server configuration.
(Such as the value of the TZ variable.)

My original idea was that by implementing ImportEnv right now, we would
make it possible (if hacky) to solve the other problems as well.

David.