Best practice on FastCGI configuration to avoid ambiguous FCGI_PARAMS keys

Most of the times when configuring a FastCGI application it is just
good enough to include the fastcgi.conf which ships with the Nginx
distribution. On the other hand sometimes it is required to just change
one or few of the definitions in that file, for example when the
application resided outside document root. Practically something like

include fastcgi.conf;
fastcgi_param DOCUMENT_ROOT /foo/bar;

worked for me so far (in combination with php-fpm(8)). While debugging
a different issue I also had a network sniffer running the traffic
between Nginx and the FastCGI application server, I found out that Nginx
takes that sort of configuration literally and transfers two
DOCUMENT_ROOT parameters, first with the setting given in fastcgi.conf
and then the one specified explicitly.

From theoretical point of view one can argue that this is a
configuration flaw, but from a practical point of view I wonder if it
wouldn’t make sense for Nginx to allow override of FCGI_PARAMS keys and
just transfer the last definition. The FastCGI specification [1] is
pretty vague on ambiguous FCGI_PARAMS keys and the order of processing.
This basically passes the ball to the FastCGI application server to sort
out what would be “best”, e.g. take the very first value definition of a
specific FCGI_PARAMS, the last one, role a dice, etc. This might lead to
the situation where the same Nginx configuration could trigger different
behavior dependent in which FastCGI application server would be used.

Again, I don’t see this directly as Nginx’s fault, the question is just
of this is desirable for the ease of system administration to keep
configurations compact and clear with still a well-defined behavior.
Reducation of network traffic between Nginx and the FastCGI application
would be another aspect.

Any other opinions on that?

-cs

[1] http://www.fastcgi.com/om_archive/kit/doc/fcgi-spec.html#S5.2

Hello!

On Thu, Aug 02, 2012 at 08:29:52AM +0200, Christoph Schug wrote:

worked for me so far (in combination with php-fpm(8)). While
specification [1] is pretty vague on ambiguous FCGI_PARAMS keys and
I tend to think that it’s more or less clarified here:

http://www.fastcgi.com/om_archive/kit/doc/fcgi-spec.html#S6.2

As params are expected to represent “CGI/1.1 environment
variables”, keys should be unique.

the order of processing. This basically passes the ball to the
FastCGI application server to sort out what would be “best”, e.g.
take the very first value definition of a specific FCGI_PARAMS, the
last one, role a dice, etc. This might lead to the situation where
the same Nginx configuration could trigger different behavior
dependent in which FastCGI application server would be used.

Moreover, it would trigger different behaviour in different
versions of the same application. E.g. php changed handling
somewhere near 5.2 (not sure about exact version) from using first
param passed to a last param passed (well, not sure again,
somewhere).

Again, I don’t see this directly as Nginx’s fault, the question is
just of this is desirable for the ease of system administration to
keep configurations compact and clear with still a well-defined
behavior. Reducation of network traffic between Nginx and the
FastCGI application would be another aspect.

Any other opinions on that?

For now nginx doesn’t impose any protocol-specific restrictions on
what may be used in fastcgi_params (as well as similar things for
other protocols), it just passes literally what configuration says
to. Matching the protocol restrictions is left as an exercise for a
system administrator.

I’m don’t think we want to require uniqueness here, but probably a
warning on duplicate fastcgi_params would be a way to go.

Maxim D.

On 2012-08-02 12:01, Maxim D. wrote:
[…]

I tend to think that it’s more or less clarified here:

http://www.fastcgi.com/om_archive/kit/doc/fcgi-spec.html#S6.2

As params are expected to represent “CGI/1.1 environment
variables”, keys should be unique.

I somehow missed that part, thanks for the hint.

[…]

I’m don’t think we want to require uniqueness here, but probably a
warning on duplicate fastcgi_params would be a way to go.

Yup, that would definitively be step forward.

Thanks
-cs

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs