Maxim Dounin Wrote:
-------------------------------------------------------

> geo $x {
> default
> "${include_path}:/my/other/include/path";
> }
>
> fastcgi_param PHP_VALUE $x;
>
> which relies on the fact that geo module doesn't
> support variables.
>
> No idea how php will handle this though, probably
> Antonio is right
> and this won't work anyway.

It works, just tested it with php-fpm. php-fpm substitutes ${var} with the value for "var" in the master .ini file (php.ini). So constructs like "${include_path}:/my/other/path" are OK to pass to the php-fpm environment, and these will be interpreted correctly. The only trouble is that the "geo" hack is kinda dirty indeed, especially so that all these variables have to be explicitly declared then in the http section, as the "geo" directive must be declared on the "http" level.

Antonio, I am certainly aware that one can write an auto_prepend_file PHP script that will set all these variables correctly, but I prefer to use server settings and skip auto_prepend_file overhead, if possible. Turns out it is possible on the php-fpm level, and not currently on the nginx level. Also, implementation of your suggestion means either changing the source code of the scripts on a number of sites and making it difficult to maintain/upgrade, or, as stated above, having auto_prepend_file overhead for every php call. No good and IMHO absolutely unnecessary and also pretty ugly, compared to what is possible with just passing the right string to the environment.

Let's wait for the nginx update!

Andrejs