Project

General

Profile

Actions
Copy link

Bug #1547

closed

conditional "add-environment"s overwrite each other / no inheritance

Added by soenke about 17 years ago. Updated over 14 years ago.

Status:
Invalid
Priority:
Normal
Category:
documentation
Target version:
-
ASK QUESTIONS IN Forums:

Description

consider the following:


$HTTP["host"] =~ ".+\.soenke\.test$" {
        setenv.add-environment = (
                "FOO" => "BAR",
        )
}

$HTTP["host"] =~ "^web\.soenke\.test$" {
        setenv.add-environment = (
                "BAR" => "FOO",
        )
}

Now the second setenv overwrites the first. My host web.soenke.test does not inherit the FOO variable. Maybe this is wanted but than the phrase "add-" is not appropriate because it's "set" indeed (imho).

BTW. it doesn't matter if you use the "+=" operator or the "=" operator.

Actions
Copy link
 #1

Updated by stbuehler about 17 years ago

  • Status changed from New to Fixed
  • Resolution set to wontfix

"adds a value to the process environment" - not to the configured environment.

This is by design, and i don't think it will change as it could break other setups and is not really a bug, you just like it do something other.

The '+=' operator is evaluated while parsing, not while matching conditions.

See http://trac.lighttpd.net/trac/ticket/1427#comment:6

Actions
Copy link
 #2

Updated by soenke about 17 years ago

  • Status changed from Fixed to Need Feedback
  • Resolution deleted (wontfix)

Hi,

I guess although it's be design this should really be noted in the manual because it's unintuitive, if you look for example at Apache which does a "real add". IMHO "add-environment" is the wrong name, it's rather "set-environment"

Additionally it's going to be really scary if you have a lot of configuration done per ENV variables and you have to copy a "global" ENV into each occurence of add-enviroment. For example, in Apache I can do a global


SetEnv TESTSERVER 1

and you have it accessible everywhere. In lighty I'll have to copy it everytime where another add-environment is configured.

I'm going to add a hint into the documentation, ok?

Mmhm, maybe this could be changed in 1.5?

Actions
Copy link
 #3

Updated by stbuehler over 16 years ago

  • Status changed from Need Feedback to Fixed
  • Resolution set to invalid

You may of course add a hint in the docs, but it is still "add-environment" - all vars from the final set of the config are added (and this is by design of the config system, so won't change in 1.5).

Actions
Copy link
 #4

Updated by stbuehler over 16 years ago

  • Status changed from Fixed to Invalid
Actions
Copy link
 #5

Updated by andrezero over 14 years ago

  • Status changed from Invalid to Reopened
  • Target version changed from 1.4.20 to 1.5.0

I'm still using lighttpd despite of the bloated config files.

Also, I suspect this behaviour has had multiple incarnations so I couldn't really agree with the breaking of user stuff and here's why:

@soenke uses setenv.add-environment = () but when I tried that in the past (multiple calls) I would get an error... so I changed my conf files to use the += operator and it worked for some time (just can't tell you when)

$HTTP["host"] =~ ".+\.pz\.worker" {
    setenv.add-environment +=(
        "DEBUG" => "127",
        "AUDIT" => "cache,template,config,db",
        "ERROR_REPORTING" => "32767",
        "DOMAIN_SYS" => .....

But it later stopped working. And I had to copy all the vars arround into every config file to make sure there is only one call to add_environment, with all the vars, per request.

So, if you can't fix this, can you otherwise create a "merge-environment" method?

The lack of this feature has a very negative impact on site.conf files.

So, given that the present behavior of add-environment is to replace previous values
regardless of operator used ( = or += )
and given this behavior is "by design"
and given you think it would break a lot user stuff if changed

could someone please be so kind as to look at Feature #2265 ?

Actions
Copy link
 #6

Updated by stbuehler over 14 years ago

  • Status changed from Reopened to Invalid
  • Target version deleted (1.5.0)
  • Missing in 1.5.x set to No
Actions
Copy link
 #7

Updated by darix over 14 years ago

your assumption how the config works is incorrect.

when a new scope is opened. the global environment is copied modified only for that scope.
the global config is untouched.
when you enter the 2nd scope the global config is copied and modified in that scope.

Actions
Copy link
 #8

Updated by Olaf-van-der-Spek over 14 years ago

darix wrote:

your assumption how the config works is incorrect.

It seems everyone's assumptions are incorrect...
To me, this looks like undesirable and unexpected behaviour due to bad design.
Is this even documented?

Actions
Copy link

Also available in: Atom