# Best practice on FastCGI configuration to avoid ambiguous FCGI\_PARAMS keys **URL:** \ **Category:** NGINX\ **Created:** [August 2, 2012, 8:30am UTC](https://www.ruby-forum.com/t/best-practice-on-fastcgi-configuration-to-avoid-ambiguous-fcgi-params-keys/221855 "2012-08-02T08:30:15Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\ **Post date:** [August 2, 2012, 8:30am UTC](https://www.ruby-forum.com/t/best-practice-on-fastcgi-configuration-to-avoid-ambiguous-fcgi-params-keys/221855/1 "2012-08-02T08:30:15Z")
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](http://www.fastcgi.com/om_archive/kit/doc/fcgi-spec.html#S5.2) ---
**Author:** ![Christoph\_Schug](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c4cdca/32.png) [@Christoph\_Schug](https://www.ruby-forum.com/u/Christoph_Schug)\ **Post date:** [August 2, 2012, 12:01pm UTC](https://www.ruby-forum.com/t/best-practice-on-fastcgi-configuration-to-avoid-ambiguous-fcgi-params-keys/221855/2 "2012-08-02T12:01:45Z")
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](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. ---
**Author:** ![Christoph\_Schug](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c4cdca/32.png) [@Christoph\_Schug](https://www.ruby-forum.com/u/Christoph_Schug)\ **Post date:** [August 2, 2012, 5:57pm UTC](https://www.ruby-forum.com/t/best-practice-on-fastcgi-configuration-to-avoid-ambiguous-fcgi-params-keys/221855/3 "2012-08-02T17:57:39Z")
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](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