Forum: NGINX Problem with inheriting fastcgi params

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 Michael Shadle (Guest)
on 2009-06-05 21:48
(Received via mailing list)
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?
2e321cc0efe9422d37165e922298494e?d=identicon&s=25 Cliff Wells (Guest)
on 2009-06-05 22:00
(Received via mailing list)
On Fri, 2009-06-05 at 12:36 -0700, Michael Shadle 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
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 Michael Shadle (Guest)
on 2009-06-05 22:04
(Received via mailing list)
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.
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2009-06-05 22:27
(Received via mailing list)
Hello!

On Fri, Jun 05, 2009 at 12:36:36PM -0700, Michael Shadle 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 Dounin
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 Michael Shadle (Guest)
on 2009-06-05 22:57
(Received via mailing list)
On Fri, Jun 5, 2009 at 1:17 PM, Maxim Dounin <mdounin@mdounin.ru> 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.
2e321cc0efe9422d37165e922298494e?d=identicon&s=25 Cliff Wells (Guest)
on 2009-06-05 23:19
(Received via mailing list)
On Sat, 2009-06-06 at 00:17 +0400, Maxim Dounin 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
2e321cc0efe9422d37165e922298494e?d=identicon&s=25 Cliff Wells (Guest)
on 2009-06-05 23:20
(Received via mailing list)
On Fri, 2009-06-05 at 13:49 -0700, Michael Shadle 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
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 Michael Shadle (Guest)
on 2009-06-06 00:05
(Received via mailing list)
On Fri, Jun 5, 2009 at 2:12 PM, Cliff Wells <cliff@develix.com> 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!
:)
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2009-06-06 04:14
(Received via mailing list)
Hello!

On Fri, Jun 05, 2009 at 02:12:50PM -0700, Cliff Wells 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 Dounin
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 Michael Shadle (Guest)
on 2009-06-06 04:45
(Received via mailing list)
On Jun 5, 2009, at 7:03 PM, Maxim Dounin <mdounin@mdounin.ru> 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?
2e321cc0efe9422d37165e922298494e?d=identicon&s=25 Cliff Wells (Guest)
on 2009-06-06 06:42
(Received via mailing list)
On Sat, 2009-06-06 at 06:03 +0400, Maxim Dounin 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 topic is locked and can not be replied to.