# Problem with inheriting fastcgi params

**URL:** <https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609>\
**Category:** NGINX\
**Created:** [June 5, 2009, 9:48pm UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609 "2009-06-05T21:48:21Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![wickie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ba9def/32.png) [@wickie](https://www.ruby-forum.com/u/wickie)\
**Post date:** [June 5, 2009, 9:48pm UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609/1 "2009-06-05T21:48:21Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![wickie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ba9def/32.png) [@wickie](https://www.ruby-forum.com/u/wickie)\
**Post date:** [June 5, 2009, 10:00pm UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609/2 "2009-06-05T22:00:41Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![wickie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ba9def/32.png) [@wickie](https://www.ruby-forum.com/u/wickie)\
**Post date:** [June 5, 2009, 10:04pm UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609/3 "2009-06-05T22:04:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![wickie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ba9def/32.png) [@wickie](https://www.ruby-forum.com/u/wickie)\
**Post date:** [June 5, 2009, 10:27pm UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609/4 "2009-06-05T22:27:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![wickie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ba9def/32.png) [@wickie](https://www.ruby-forum.com/u/wickie)\
**Post date:** [June 5, 2009, 10:57pm UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609/5 "2009-06-05T22:57:43Z")

</div>

On Fri, Jun 5, 2009 at 1:17 PM, Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.

---

<div class="post-metadata">

**Author:** ![wickie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ba9def/32.png) [@wickie](https://www.ruby-forum.com/u/wickie)\
**Post date:** [June 5, 2009, 11:20pm UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609/6 "2009-06-05T23:20:05Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![wickie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ba9def/32.png) [@wickie](https://www.ruby-forum.com/u/wickie)\
**Post date:** [June 6, 2009, 12:05am UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609/7 "2009-06-06T00:05:57Z")

</div>

On Fri, Jun 5, 2009 at 2:12 PM, Cliff W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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!  
🙂

---

<div class="post-metadata">

**Author:** ![wickie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ba9def/32.png) [@wickie](https://www.ruby-forum.com/u/wickie)\
**Post date:** [June 6, 2009, 4:14am UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609/8 "2009-06-06T04:14:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![wickie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ba9def/32.png) [@wickie](https://www.ruby-forum.com/u/wickie)\
**Post date:** [June 6, 2009, 4:45am UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609/9 "2009-06-06T04:45:45Z")

</div>

On Jun 5, 2009, at 7:03 PM, Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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?

---

<div class="post-metadata">

**Author:** ![wickie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ba9def/32.png) [@wickie](https://www.ruby-forum.com/u/wickie)\
**Post date:** [June 5, 2009, 11:19pm UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609/10 "2009-06-05T23:19:29Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![wickie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ba9def/32.png) [@wickie](https://www.ruby-forum.com/u/wickie)\
**Post date:** [June 6, 2009, 6:42am UTC](https://www.ruby-forum.com/t/problem-with-inheriting-fastcgi-params/169609/11 "2009-06-06T06:42:37Z")

</div>

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