Fastcgi_pass inheritance

Hi,

I’ve been trying to get a setup like this to work:

location /fastcgi {
fastcgi_pass …;
}
location /fastcgi/specialscript {
error_page 500 …;
}

However, the existance of a location directive seems to make
fastcgi_pass stop working – it only works once I duplicate that
directive (as well as any fastcgi related directive).

Is there a better way to set settings on a specific part of the upstream
fastcgi tree without duplicating stuff in the config file?

  • Ben

Ben Maurer wrote:

Inheritance works through nesting, not through substring matching:

 location /fastcgi {
     fastcgi_pass ...;

     location /fastcgi/specialscript {
         error_page 500 ...;
     }
 }

Evan M. wrote:

Inheritance works through nesting, not through substring matching:

location /fastcgi {
    fastcgi_pass ...;

    location /fastcgi/specialscript {
        error_page 500 ...;
    }
}

That configuration still doesn’t work, the fastcgi isn’t processed for
specialscript

-b

On Sat, Dec 29, 2007 at 08:39:56PM -0500, Ben Maurer wrote:

fastcgi_pass stop working – it only works once I duplicate that
directive (as well as any fastcgi related directive).

Subject: Re: fastcgi_pass inheritance

nginx does not inherit configuration in run time from location to
location.

Is there a better way to set settings on a specific part of the upstream
fastcgi tree without duplicating stuff in the config file?

You may describe all fastcgi stuff (fastcgi_param/etc) except
fastcgi_pass
even on http level, and it will be inherited to all servers and
locations
until will be overriden in them.

Igor S. <is@…> writes:

You may describe all fastcgi stuff (fastcgi_param/etc) except fastcgi_pass
even on http level, and it will be inherited to all servers and locations
until will be overriden in them.

How this can be done? I mean how to fill all fastcgi stuff on http
level.
Currently I fill all of them inside a location ~ .php$ {…} block. Can
I use
such a location block on http level, common for all virtual servers?

Athan

Athan D. ha scritto:

Igor S. <is@…> writes:

You may describe all fastcgi stuff (fastcgi_param/etc) except fastcgi_pass
even on http level, and it will be inherited to all servers and locations
until will be overriden in them.

How this can be done? I mean how to fill all fastcgi stuff on http level.
Currently I fill all of them inside a location ~ .php$ {…} block. Can I use
such a location block on http level, common for all virtual servers?

Yes, you can.

Manlio P.

You can also move your common fast_cgi related configuration into a
seperate include file, then include /path/to/fast_cgi.conf in the
relevant server {} blocks.

Cheers

Dave

Manlio P. <manlio_perillo@…> writes:

Athan D. ha scritto:

Igor S. <is@…> writes:

You may describe all fastcgi stuff (fastcgi_param/etc) except fastcgi_pass
even on http level, and it will be inherited to all servers and locations
until will be overriden in them.

How this can be done? I mean how to fill all fastcgi stuff on http level.
Currently I fill all of them inside a location ~ .php$ {…} block. Can I
use

such a location block on http level, common for all virtual servers?

Yes, you can.

Hmm, are you sure that location can be used inside http? I’ve tried but
Nginx
replied with an error saying: “location” directive is not allowed
here…

Athan

Dave C. <dave@…> writes:

You can also move your common fast_cgi related configuration into a
seperate include file, then include /path/to/fast_cgi.conf in the
relevant server {} blocks.

I think doing that is the same as repeating the entries in each
location, it
doesn’t inherit values from a common block.

Athan

Athan D. ha scritto:

such a location block on http level, common for all virtual servers?

Yes, you can.

Hmm, are you sure that location can be used inside http? I’ve tried but Nginx
replied with an error saying: “location” directive is not allowed here…

location can not be used inside http block, but you can use the fastcgi
directives here.

The only problem is with fastcgi_param.
I’m not sure, but if you do something like:

http {
fastcgi_param x y;
fastcgi_param a b;

server {
    location / {
        fastcgi_param c d;

        fastcgi_pass ...
    }
}

}

then the FASTCGI parameters passed to the FASTCGI server at / will
receive only the c:d pair.

At least this is what happens with wsgi_var in wsgi module.

Athan

Manlio P.

Manlio P. a écrit :

How this can be done? I mean how to fill all fastcgi stuff on http
allowed here…
fastcgi_param x y;

then the FASTCGI parameters passed to the FASTCGI server at / will
receive only the c:d pair.

At least this is what happens with wsgi_var in wsgi module.

I had the same ‘issue’ with my proxy configuration. At the http level I
include a proxy.conf file but if I change any parameter (besides
proxy_pass) on a location level all the other params are ignored, and I
muse reinclude the proxy.conf file.

Jean-Philippe ha scritto:

http {
}
muse reinclude the proxy.conf file.

But this should only happen with directives that are stored as arrays,
such as (unverified) fastcgi_param, fastcgi_pass_header,
fastcgi_hide_header, fastcgi_catch_stderr, proxy_set_header,
proxy_pass_header and proxy_hide_header.

Manlio P.

On Wed, Jan 02, 2008 at 03:40:03PM +0100, Manlio P. wrote:

How this can be done? I mean how to fill all fastcgi stuff on http
here…
fastcgi_param x y;

then the FASTCGI parameters passed to the FASTCGI server at / will
receive only the c:d pair.

Usually all fastcgi_param’s are common and the only SCRIPT_FILENAME is
required to set per server. So it could configured:

http {
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;;
fastcgi_param QUERY_STRING $query_string;

server {

    location \.php$ {
        root   /path/to/script;
        fastcgi_pass   ...;

Igor S. ha scritto:

[…]

Hi Igor, happy new year!

    location \.php$ {
        root   /path/to/script;
        fastcgi_pass   ...;

The problems is that someone finds not “obvious” the inheritance
behaviour of directives stored as arrays, like fastcgi_param.

Manlio P.

On Thu, Jan 03, 2008 at 07:25:07PM +0100, Manlio P. wrote:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;;

The problems is that someone finds not “obvious” the inheritance
behaviour of directives stored as arrays, like fastcgi_param.

The fastcgi_param internal implementation as array should not
affect to user expectation of inheritance.
If fastcgi_param’s would be partailly inherited, then there should be
directive to cancel this inheritance.
Right now any fastcgi_param directive cancels inheritance.

Igor S. <is@…> writes:

Usually all fastcgi_param’s are common and the only SCRIPT_FILENAME is
required to set per server. So it could configured:

SCRIPT_FILENAME?
I think you mean fastcgi_pass.

Athan

On Thu, Jan 03, 2008 at 09:27:30PM +0000, Athan D. wrote:

Igor S. <is@…> writes:

Usually all fastcgi_param’s are common and the only SCRIPT_FILENAME is
required to set per server. So it could configured:

SCRIPT_FILENAME?

Yes.

I think you mean fastcgi_pass.

And fastcgi_pass.

The fastcgi_pass, proxy_pass, memcached_pass, perl, flv, and empty_gif
are
special directives those set location handler. If no location handler
was set, then default stack of handler is used: index, autoindex, dav,
gzip_static, and static.

The most other proxy/fastcgi directives may be inherited from http
level.

Athan D. ha scritto:

Igor S. <is@…> writes:

Usually all fastcgi_param’s are common and the only SCRIPT_FILENAME is
required to set per server. So it could configured:

SCRIPT_FILENAME?
I think you mean fastcgi_pass.

No, it is correct.
SCRIPT_FILENAME should be set on a per server basis, since it points to
the location of the PHP application scripts.

Athan

Manlio P.

Igor S. <is@…> writes:

was set, then default stack of handler is used: index, autoindex, dav,
gzip_static, and static.

The most other proxy/fastcgi directives may be inherited from http level.

Thanks for the detailed explanation, Igor.
BTW, is there any performance hit/gain by declaring fastcgi_xxx
directives at
http level instead a location block, especially a regex one (e.g “~
.php$”)

Athan

Manlio P. <manlio_perillo@…> writes:

No, it is correct.
SCRIPT_FILENAME should be set on a per server basis, since it points to
the location of the PHP application scripts.

You’re right, thank Manlio.

Athan