# Possible to overwrite a fastcgi\_param "later", once a location block has already been closed?

**URL:** <https://www.ruby-forum.com/t/possible-to-overwrite-a-fastcgi-param-later-once-a-location-block-has-already-been-closed/235700>\
**Category:** NGINX\
**Created:** [July 9, 2013, 10:49pm UTC](https://www.ruby-forum.com/t/possible-to-overwrite-a-fastcgi-param-later-once-a-location-block-has-already-been-closed/235700 "2013-07-09T22:49:17Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![alcina](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a587f6/32.png) [@alcina](https://www.ruby-forum.com/u/alcina)\
**Post date:** [July 9, 2013, 10:49pm UTC](https://www.ruby-forum.com/t/possible-to-overwrite-a-fastcgi-param-later-once-a-location-block-has-already-been-closed/235700/1 "2013-07-09T22:49:17Z")

</div>

Hello,

I am working with a server configuration that is partly outside of my  
control, and have a need to overwrite a fastcgi\_param “after” the  
directives that are outside of my control have already been included.

The basics of the configuration are:

* * *

# […]

location ~ .php$ {  
try\_files /2ed86bea62460140e9b23d047f7d68b1.htm @php;  
}

location @php {  
try\_files $uri =404;  
include /etc/nginx/fastcgi\_params;  
fastcgi\_pass 127.0.0.1:9013;  
fastcgi\_index index.php;  
fastcgi\_param SCRIPT\_FILENAME $document\_root$fastcgi\_script\_name;  
fastcgi\_intercept\_errors on;  
}

# At this point, the fastcgi\_param values have already been defined.

# This is the include file that I am able to modify.

## include my-include.conf

Is it possible for me to overwrite the values that are defined on the  
line “include /etc/nginx/fastcgi\_params;” from within the included file  
that I can modify, “my-include.conf”?

In particular, I would like to hard-code the SERVER\_NAME value within  
“my-include.conf”.

Thanks for any help,

-Ben

---

<div class="post-metadata">

**Author:** ![benjohnson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3ec8ea/32.png) [@benjohnson](https://www.ruby-forum.com/u/benjohnson)\
**Post date:** [July 9, 2013, 11:48pm UTC](https://www.ruby-forum.com/t/possible-to-overwrite-a-fastcgi-param-later-once-a-location-block-has-already-been-closed/235700/2 "2013-07-09T23:48:19Z")

</div>

On Tue, Jul 09, 2013 at 04:48:27PM -0400, Ben J. wrote:

Hi there,

> I am working with a server configuration that is partly outside of my  
> control,

I suspect that that’s not the intended use case for nginx. Whoever  
writes  
the config file has the opportunity to configure it not to start.

> and have a need to overwrite a fastcgi\_param “after” the  
> directives that are outside of my control have already been included.

That sentence is possible; but not the one in your Subject: line.

> # This is the include file that I am able to modify.
> 
> include my-include.conf

That line must be within the “location @php” block, in order for it to  
do what you want.

(Otherwise, you could try completely hijacking the config by using  
something like

location ^~ / {  
location ~ php$ {  
# you control what goes here  
}  
# and what goes here  
}

in my-include.conf, but that would be a good way to lose config  
privileges  
on the server.)

> Is it possible for me to overwrite the values that are defined on the  
> line “include /etc/nginx/fastcgi\_params;” from within the included file  
> that I can modify, “my-include.conf”?

Current nginx sends all fastcgi\_params that are defined, in order; so  
if you set the same one multiple times in the same context, all are  
sent.

Your fastcgi server probably only pays attention to the first one  
received, or maybe to the last one received. Test to find out.

When you know which it is, put your “include” line before or after the  
other “include” line, and see how it works.

Future nginx may stop sending all repeated fastcgi\_params. If you change  
fastcgi server, the one it pays attention to may change. So your testing  
should be repeated after every upgrade.

## f

Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![benjohnson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3ec8ea/32.png) [@benjohnson](https://www.ruby-forum.com/u/benjohnson)\
**Post date:** [July 10, 2013, 2:13am UTC](https://www.ruby-forum.com/t/possible-to-overwrite-a-fastcgi-param-later-once-a-location-block-has-already-been-closed/235700/3 "2013-07-10T02:13:50Z")

</div>

On 7/9/2013 5:47 PM, Francis D. wrote:

> On Tue, Jul 09, 2013 at 04:48:27PM -0400, Ben J. wrote:
> 
> Hi there,
> 
> > I am working with a server configuration that is partly outside of my  
> > control,
> 
> I suspect that that’s not the intended use case for nginx. Whoever writes  
> the config file has the opportunity to configure it not to start.

To be clear, this lack of control is not due to a lack of privileges; I  
use ISPConfig, which has its own way of doing things (and it usually  
knows best, based on past experience).

> > and have a need to overwrite a fastcgi\_param “after” the  
> > directives that are outside of my control have already been included.
> 
> That sentence is possible; but not the one in your Subject: line.

I see; there is a distinction to be made. Thanks for making it. 🙂

> > # This is the include file that I am able to modify.
> > 
> > include my-include.conf
> 
> That line must be within the “location @php” block, in order for it to  
> do what you want.

Okay; this means that I would need to modify the ISPConfig virtual host  
template for nginx. I would love to avoid that, if at all possible, for  
compatibility with future ISPConfig releases.

> in my-include.conf, but that would be a good way to lose config privileges  
> on the server.)

No concerns in this regard; I administer the server. But it seems like  
taking that measure would defeat the purpose of using ISPConfig.

> > Is it possible for me to overwrite the values that are defined on the  
> > line “include /etc/nginx/fastcgi\_params;” from within the included file  
> > that I can modify, “my-include.conf”?
> 
> Current nginx sends all fastcgi\_params that are defined, in order; so  
> if you set the same one multiple times in the same context, all are sent.

I see. Presumably, if I set the same fastcgi\_param multiple times in  
different contexts, any content in which inheritance applies will  
overwrite any previously-defined value with the new value. Is this  
presumption correct? It seems so, based on the documentation regarding  
fastcgi\_params.

> Your fastcgi server probably only pays attention to the first one  
> received, or maybe to the last one received. Test to find out.
> 
> When you know which it is, put your “include” line before or after the  
> other “include” line, and see how it works.

It seems that my FastCGI service is concerned with the last value only.  
If I place the my preferred value after ISPConfig’s include line, it is  
honored.

> Future nginx may stop sending all repeated fastcgi\_params. If you change  
> fastcgi server, the one it pays attention to may change. So your testing  
> should be repeated after every upgrade.
> 
> f

Perhaps it is prudent to proceed under this proviso. Maybe I can find a  
way to make this work, using ISPConfig’s configuration template  
“merging” functionality, to make this work.

I’ll post back with my findings.

Thanks for all your help, Francis. Very thorough, as always.

-Ben

---

<div class="post-metadata">

**Author:** ![benjohnson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3ec8ea/32.png) [@benjohnson](https://www.ruby-forum.com/u/benjohnson)\
**Post date:** [July 10, 2013, 11:21pm UTC](https://www.ruby-forum.com/t/possible-to-overwrite-a-fastcgi-param-later-once-a-location-block-has-already-been-closed/235700/4 "2013-07-10T23:21:32Z")

</div>

On Tue, Jul 09, 2013 at 08:13:16PM -0400, Ben J. wrote:

> On 7/9/2013 5:47 PM, Francis D. wrote:

Hi there,

> > That line must be within the “location @php” block, in order for it to  
> > do what you want.
> 
> Okay; this means that I would need to modify the ISPConfig virtual host  
> template for nginx. I would love to avoid that, if at all possible, for  
> compatibility with future ISPConfig releases.

You could just modify /etc/nginx/fastcgi\_params, but that may not suit  
depending on other considerations.

> > (Otherwise, you could try completely hijacking the config by using

> No concerns in this regard; I administer the server. But it seems like  
> taking that measure would defeat the purpose of using ISPConfig.

Correct.

The usual nginx rules of one request is handled in one location, and  
inheritance is by replacement or not at all, mean this is so.

> I see. Presumably, if I set the same fastcgi\_param multiple times in  
> different contexts, any content in which inheritance applies will  
> overwrite any previously-defined value with the new value. Is this  
> presumption correct?

If you set any fastcgi\_param in one context, no fastcgi\_param is  
inherited  
into that context.

> > Future nginx may stop sending all repeated fastcgi\_params. If you change  
> > fastcgi server, the one it pays attention to may change. So your testing  
> > should be repeated after every upgrade.

> Perhaps it is prudent to proceed under this proviso.

On the nginx side, if it does ever stop sending multiple values,  
presumably it will be clear which single value it will send. At that  
point, it won’t matter what your fastcgi server does with multiple  
values. So it’s a relatively straightforward test after each upgrade.

> Maybe I can find a  
> way to make this work, using ISPConfig’s configuration template  
> “merging” functionality, to make this work.

The good news is that nginx doesn’t care how the config file is created  
🙂

You can add your “include” directive, or you can use an external macro  
function to get the right lines into the right location.

Possibly this tool has a facility like that.

> Thanks for all your help, Francis. Very thorough, as always.

Cheers; good luck with it,

## f

Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)