Possible to overwrite a fastcgi_param "later", once a location block has already been closed?

Francis Daly francis at daoine.org
Wed Jul 10 21:21:04 UTC 2013


On Tue, Jul 09, 2013 at 08:13:16PM -0400, Ben Johnson wrote:
> On 7/9/2013 5:47 PM, Francis Daly 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 Daly        francis at daoine.org



More information about the nginx mailing list