Fastcgi_param in server context does not work

Tomasz_P · September 22, 2009, 8:01pm

When I set fastcgi_param in server context it is not set, if in location
it is set.
Wiki says it should work in http, server, location context.

server {
listen 80;
server_name .landingpage.dev;
access_log off;
error_log /var/log/nginx/landingpage.log;

root /vhosts/landingpage/public;
charset utf-8;

fastcgi_index index.php;
fastcgi_param SITE my_site;

location / {
    try_files $uri $uri/ @fallback;
    fastcgi_pass unix:/var/run/spawn-fcgi.sock;
    fastcgi_param SCRIPT_FILENAME

$document_root/$fastcgi_script_name;
#fastcgi_param SITE my_site;
include fastcgi_params;
}

location @fallback {
    fastcgi_pass unix:/var/run/spawn-fcgi.sock;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    #fastcgi_param SITE my_site;
    include fastcgi_params;
}

}

Tomasz_P · September 22, 2009, 8:03pm

it does work but you overwrite it in your location, i believe.

any of the “array” settings can’t be mixed or the most local copy seems
to win.

Tomasz_P · September 23, 2009, 12:41am

Hello!

On Tue, Sep 22, 2009 at 05:17:53PM +0200, Tomasz P. wrote:

When I set fastcgi_param in server context it is not set, if in
location it is set.
Wiki says it should work in http, server, location context.

Please note that wiki also says:

Directives not set are inherited from the outer level. Directives set in current level clear any previously defined directives for the current level.

Note that this is standard behaviour for all array-type directives
(fastcgi_param, proxy_set_header, access_log, error_log and so on).

Maxim D.

Tomasz_P · September 23, 2009, 8:04am

the current level.

Note that this is standard behaviour for all array-type directives
(fastcgi_param, proxy_set_header, access_log, error_log and so on).

Yes I agree but there is no active fastcgi_param SITE in location
context.

Tomasz_P · September 23, 2009, 10:16am

array with a new one. not just replacing a specific key or appending
to it.

So there is no way to create such a configuration:

fastcgi.conf

root /vhosts/landingpage/public;
charset utf-8;

fastcgi_index index.php;

location / {
try_files $uri $uri/ @fallback;
fastcgi_pass unix:/var/run/spawn-fcgi.sock;
fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
include fastcgi_params;
}

location @fallback {
fastcgi_pass unix:/var/run/spawn-fcgi.sock;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
include fastcgi_params;
}

landingpage.conf

server {
listen 80;
server_name .site1.landingpage.dev;
access_log off;
error_log /var/log/nginx/site1.landingpage.log;

fastcgi_param SITE site1;
include fastcgi.conf;

}

server {
listen 80;
server_name .site2.landingpage.dev;
access_log off;
error_log /var/log/nginx/site2.landingpage.log;

fastcgi_param SITE site2;
include fastcgi.conf;

}

Tomasz_P · September 23, 2009, 9:24am

On Tue, Sep 22, 2009 at 10:57 PM, Tomasz P. [email protected] wrote:

Yes I agree but there is no active fastcgi_param SITE in location context.

no but the location context’s array overwrites the array that was
defined on the server level

i used to think the same thing - that it’s all key based; but
apparently it’s not. think of it like a php array, and replacing the
array with a new one. not just replacing a specific key or appending
to it.

Tomasz_P · September 23, 2009, 11:55am

Tomasz P. wrote:

fastcgi_pass unix:/var/run/spawn-fcgi.sock;

landingpage.conf

server {
listen 80;
server_name .site2.landingpage.dev;
access_log off;
error_log /var/log/nginx/site2.landingpage.log;

fastcgi_param SITE site2;
include fastcgi.conf;
}
I’ve been going through emails, and I came up with a good solution to my
configuration, based on Igor and Maxim suggestion in Conditional
fastcgi_param thread.
Thanks!

landingpage-fastcgi.conf

access_log off;
root /vhosts/landingpage/public;
charset utf-8;
fastcgi_index index.php;

location / {
try_files $uri $uri/ @fallback;
fastcgi_pass unix:/var/run/spawn-fcgi.sock;
fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
fastcgi_param SITE $landingpage_site;
include fastcgi_params;
}

location @fallback {
fastcgi_pass unix:/var/run/spawn-fcgi.sock;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param SITE $landingpage_site;
include fastcgi_params;
}

landingpage.conf

map $http_host $landingpage_site {
default site1;
.site1.landingpage.dev site1;
.site2.landingpage.dev site2;
}

server {
listen 80;
server_name .landingpage.dev .site1.landingpage.dev;
error_log /var/log/nginx/landingpage/site1-error.log;
include landingpage-fastcgi;
}

server {
listen 80;
server_name .site2.landingpage.dev;
error_log /var/log/nginx/landingpage/site2-error.log;
include landingpage-fastcgi;
}

Tomasz_P · September 23, 2009, 1:14pm

Hello!

On Wed, Sep 23, 2009 at 03:14:10AM -0700, Michael S. wrote:

i used to set fastcgi_params on the global level, but now i have a
fastcgi.conf file with all the params that i include in my location
block for php - this allows me to alter the array like one would
expect.

Note that you can’t redefine params already defined on the same
level. I.e. writing (either direct or via include)

fastcgi_param  SOMETHING  1;
fastcgi_param  SOMETHING  2;

will send two name-value pairs to fastcgi application. It’s up to
application to use either both or one of them.

In practice, PHP is known to behave differently in different
versions. After 5.2 it uses last value supplied, before - first
one.

Maxim D.

Tomasz_P · September 23, 2009, 6:58pm

Oh, wow.

To me, that seems like a bug, or at least an unwanted behavior. That
doesn’t really follow any kind of pattern I’ve ever seen.

I can’t see the need to pass the same pair twice for any reason - if
so I’d think it would be something like

fastcgi_param SOMETHING[] 1;
fastcgi_param SOMETHING[] 2;

or something along those lines if someone -really- wanted two values.

2009/9/23 Maxim D. [email protected]:

Tomasz_P · September 23, 2009, 7:38pm

Hello!

On Wed, Sep 23, 2009 at 09:51:12AM -0700, Michael S. wrote:

Oh, wow.

To me, that seems like a bug, or at least an unwanted behavior. That
doesn’t really follow any kind of pattern I’ve ever seen.

This is how it works, and fastcgi specs do not specify intended
behaviour here. It’s up to application to select one. In it’s
turn nginx just allow admin to do whatever his application wants.

Note that this problem was already discussed on Russian mailing
list a while ago and consesus was that such situation probably
deserves warning during configuration parsing.

For now, just don’t write duplicate fastcgi_param’s if you don’t
need them and you will be fine.

Maxim D.

Tomasz_P · September 23, 2009, 12:21pm

i used to set fastcgi_params on the global level, but now i have a
fastcgi.conf file with all the params that i include in my location
block for php - this allows me to alter the array like one would
expect.

Tomasz_P · September 23, 2009, 7:44pm

2009/9/23 Maxim D. [email protected]:

For now, just don’t write duplicate fastcgi_param’s if you don’t
need them and you will be fine.

I don’t unless I am expecting to overwrite one on a case-by-case basis