remove duplicate nginx fastcgi params

Redundant config has been removed from the main config file: http://drupalcode.org/project/provision.git/commit/c74f5af

I recall it was put there after some request to support non-drupal sites/vhosts, but this can be done easily by including params like every vhost do.

The reason there are two copies is that fastcgi_ssl_params.conf includes hardcoded fastcgi_param HTTPS on;, which is required for SSL enabled sites, and using just separate copy is more sane than some funky on the fly tweaks. Also, removing it would break all sites using it, until re-verified.

This file is critically important, so I'm against using shipped (or not) and Drupal compatible (or not) version.

Even if we assume that the shipped version will not break things on some upgrade in the future (and this is already too optimistic), there are some known problems with the defaults used.

While using $request_filename for SCRIPT_FILENAME is as good as using $document_root$fastcgi_script_name it is good only thanks to the rewrites we have in place, as otherwise it would never work for Drupal with clean URLs enabled.

But using $https variable for fastcgi_param HTTPS is something which requires Nginx version >= 1.1.11 and this would break support for current Debian and Ubuntu LTS versions. That is why we use separate copy for SSL enabled vhosts with HTTPS hardcoded.

For HTTPS - can't we just override the variable for < 1.1?

We would need to *define* this variable in the server.tpl.php template for older Nginx versions and add yet another check for Nginx version used, but it is doable, of course.

SCRIPT_FILENAME - can we use the upstream value or not

Yes, as long as we have the current logic/rewrites for handling clean URLs in the config include.

As to whether or not we can rely on the upstream configuration file being there, I'd like to see some actual data as to whether or not that file is available outside of debian (say in a stock Nginx install).

Good question. There are bad news. Stock Nginx (just checked latest 1.4.0) comes with fastcgi_params file below:

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

Note that it doesn't include the line:

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

And it includes the line:

fastcgi_param  HTTPS              $https if_not_empty;

Where "if_not_empty" requires Nginx version >= 1.1.11

But! The old Nginx versions (from sources) come without HTTPS line at all, so we would have to set them in the vhost (!), which requires that the vhost must be up-to-date (the site re-verified), which only further complicates things, because we would have to check Nginx version on every site verify (not just server verify).

This is exactly why I'm against using shipped (or not) and Drupal compatible (or not) fastcgi_params version - because the defaults are unreliable and are OS distro (or Nginx source) specific and we are only adding unpredictable complexity here, instead of simply ship the same two files we ship so far, which doesn't require any extra version check, because we don't use version specific variables for HTTPS.

The problem is that we can't assume what is available, because the "upstream" includes different stuff if installed from packages and from sources, and adding more layers of complexity with cross checks in Provision is just an exact opposite to KISS methodology. I think I have provided enough proof that we can't reliably rely on the "upstream" for fastcgi_params and it is too critically important to play with checks and workarounds etc.

Fixed in http://drupalcode.org/project/provision.git/commit/fca8e64

It required a few more commits to get really fixed and working:

http://drupalcode.org/project/provision.git/commit/5e9775d
http://drupalcode.org/project/provision.git/commit/b43c203
http://drupalcode.org/project/provision.git/commit/7c6c599