Best practice on FastCGI configuration to avoid ambiguous FCGI_PARAMS keys

[Maxim Dounin]

Hello!

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

> 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

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 Dounin