Problem with inheriting fastcgi params

I have my normal fastcgi params in my main nginx.conf file, under server
{}

i.e.:

fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $http_host;
fastcgi_ignore_client_abort on;
fastcgi_buffers 32 8k;
fastcgi_index index.php;

The problem is, whenever I want to add a variable (maybe override too,
I forget) it seems to clear all the other ones out:

           location ~ \.php$ {
                    fastcgi_pass 127.0.0.1:11003;
                    fastcgi_param HTTPS on;
            }

Now, only fastcgi_param HTTPS is set. no more SCRIPT_FILENAME so it’s
broken.

I would assume it would be able to inherit everything globally and
only add to the fastcgi_params on demand.

This is using nginx 0.7.55 or thereabouts but it’s been an issue I’ve
noticed in the past too.

Can nginx support this?

On Fri, 2009-06-05 at 12:36 -0700, Michael S. wrote:

fastcgi_param REQUEST_URI $request_uri;
fastcgi_ignore_client_abort on;
}

Now, only fastcgi_param HTTPS is set. no more SCRIPT_FILENAME so it’s broken.

I would assume it would be able to inherit everything globally and
only add to the fastcgi_params on demand.

This is using nginx 0.7.55 or thereabouts but it’s been an issue I’ve
noticed in the past too.

Can nginx support this?

Put your params in a separate file and include them wherever they are
needed:

location ~ .php$ {
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:11003;
fastcgi_param HTTPS on;
}

This doesn’t incur any additional overhead.

Cliff

I used to do that but realized I could do it the other way.

First I’d like to know if this is even supported. Might be a tiny bug
that could wind up messing up something else.

Depending on the outcome, I’ll probably wind up moving out the stuff
to a fastcgi_params anyway, though.

Hello!

On Fri, Jun 05, 2009 at 12:36:36PM -0700, Michael S. wrote:

fastcgi_param REQUEST_URI $request_uri;
fastcgi_ignore_client_abort on;
}

Now, only fastcgi_param HTTPS is set. no more SCRIPT_FILENAME so it’s broken.

It’s expected and documented behaviour. All array-type settings
behave like this: they are inherited from upper levels only if
none defined at this particular level.

Maxim D.

On Fri, Jun 5, 2009 at 1:17 PM, Maxim D. [email protected] wrote:

fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param REMOTE_PORT $remote_port;

        location ~ .php$ {
            fastcgi_pass 127.0.0.1:11003;
            fastcgi_param HTTPS on;
        }

Now, only fastcgi_param HTTPS is set. no more SCRIPT_FILENAME so it’s broken.

It’s expected and documented behaviour. Â All array-type settings
behave like this: they are inherited from upper levels only if
none defined at this particular level.

So instead of appending the array (or replacing an existing index) I
am essentially resetting the array completely?

Is there a usage model where it makes sense that this should be a
supported behavior? Logically it seems like it should be supported,
but I guess under the hood it’s a one line change or a very major
change.

On Fri, 2009-06-05 at 13:49 -0700, Michael S. wrote:

fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param REMOTE_ADDR $remote_addr;
I forget) it seems to clear all the other ones out:
none defined at this particular level.

So instead of appending the array (or replacing an existing index) I
am essentially resetting the array completely?

Is there a usage model where it makes sense that this should be a
supported behavior? Logically it seems like it should be supported,
but I guess under the hood it’s a one line change or a very major
change.

I believe the idea is that inheritance can lead to subtle side-effects
in large configurations. You might include a several files and not
realize that one of them is affecting the configuration several
files/locations away.

Cliff

On Fri, Jun 5, 2009 at 2:12 PM, Cliff W. [email protected] wrote:

Interesting. Â I was aware of the limitation Michael mentions, but
didn’t realize this was the particular mechanism. Â So I assume that
“array-type” is indicated by the variable prefixes, i.e. fastcgi_,
proxy_
, etc?

See, there -is- a use case out there somewhere!
:slight_smile:

Hello!

On Fri, Jun 05, 2009 at 02:12:50PM -0700, Cliff W. wrote:

fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param REMOTE_ADDR $remote_addr;
I forget) it seems to clear all the other ones out:
none defined at this particular level.

Interesting. I was aware of the limitation Michael mentions, but
didn’t realize this was the particular mechanism. So I assume that
“array-type” is indicated by the variable prefixes, i.e. fastcgi_,
proxy_
, etc?

Yes, it’s generic mechanism. No, “array-type” isn’t indicated by
anything. It’s just includes any directives that may be repeated
and effectively append items to some array internally. This
includes access_log, error_log, fastcgi_param, proxy_set_header,
ssi_types (and other *_types as well), access rules (allow + deny)
and so on.

From user-level point of view this behaviour is part of config
syntax. If it wasn’t working this way - some other syntax would be
required to make it possible to clear inherited values.

From developer point of view - it’s just easy. Inheritance
involve just copy of array pointer from upper level if there are
no directives defined at particular level.

Maxim D.

On Jun 5, 2009, at 7:03 PM, Maxim D. [email protected] wrote:

server {}
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_buffers 32 8k;
}
“array-type” is indicated by the variable prefixes, i.e. fastcgi_*,
syntax. If it wasn’t working this way - some other syntax would be
required to make it possible to clear inherited values.

From developer point of view - it’s just easy. Inheritance
involve just copy of array pointer from upper level if there are
no directives defined at particular level.

Doesn’t that mean it could be supported how I originally had asked?

On Sat, 2009-06-06 at 00:17 +0400, Maxim D. wrote:

fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param REMOTE_PORT $remote_port;

           location ~ \.php$ {
                    fastcgi_pass 127.0.0.1:11003;
                    fastcgi_param HTTPS on;
            }

Now, only fastcgi_param HTTPS is set. no more SCRIPT_FILENAME so it’s broken.

It’s expected and documented behaviour. All array-type settings
behave like this: they are inherited from upper levels only if
none defined at this particular level.

Interesting. I was aware of the limitation Michael mentions, but
didn’t realize this was the particular mechanism. So I assume that
“array-type” is indicated by the variable prefixes, i.e. fastcgi_,
proxy_
, etc?

If you’ll confirm this, I’ll get it into the FAQ.

Cliff

On Sat, 2009-06-06 at 06:03 +0400, Maxim D. wrote:

didn’t realize this was the particular mechanism. So I assume that
From user-level point of view this behaviour is part of config
syntax. If it wasn’t working this way - some other syntax would be
required to make it possible to clear inherited values.

From developer point of view - it’s just easy. Inheritance
involve just copy of array pointer from upper level if there are
no directives defined at particular level.

I guess what I’m looking for (from a user point of view), is how to
describe why (and more importantly when) setting one variable affects
others. If there were an obvious pattern in naming conventions (or
even a simple, externally maintained list in the wiki) of array
variables I think it would make this behavior less surprising. I write
a bit of code myself, so your description makes perfect sense as to how
things work internally, but this doesn’t necessarily lend itself (from a
user perspective) to predicting which variables might fall into this
category.

Cliff

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs