Nginx $document_root$fastcgi_script_name vs $request_filename

Question

I can't notice any difference if in my config file I set

 fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

Or:

 fastcgi_param  SCRIPT_FILENAME    $request_filename;

What do they do respectively? Is one of the two better than the other?

Thanks in advance.

Answer 1

Here's what the documentation says:

$request_filename

This variable is equal to path to the file for the current request, formed from directives root or alias and URI request;

$document_root

This variable is equal to the value of directive root for the current request;

$fastcgi_script_name

This variable is equal to the URI request or, if if the URI concludes with a forward slash, then the URI request plus the name of the index file given by fastcgi_index. It is possible to use this variable in place of both SCRIPT_FILENAME and PATH_TRANSLATED, utilized, in particular, for determining the name of the script in PHP.

As written here, there's at least a difference when using fastcgi_index or fastcgi_split_path_info. Maybe there are more ... that's what I know of right now.

Example

You get the request /info/ and have the following configuration:

fastcgi_index  index.php;
fastcgi_param  SCRIPT_FILENAME  /home/www/scripts/php$fastcgi_script_name;

SCRIPT_FILENAME would equal /home/www/scripts/php/info/index.php, but using $request_filename it would just be /home/www/scripts/php/info/.

The configuration of fastcgi_split_path_info is important as well. See here for further help: http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_split_path_info

Answer 2

If need PATH_INFO

If need PATH_INFO (URI like /index.php/search), you need to use $document_root$fastcgi_script_name, because fastcgi_split_path_info cannot use $request_filename

If using root directive

$document_root$fastcgi_script_name is equal to $request_filename.

If using alias directive

$document_root$fastcgi_script_name will return the wrong path, because $fastcgi_script_name is path of the URI, not the path relate to $document_root.

Example

location /api/ {
    index  index.php index.html index.htm;
    alias /app/www/;
    location ~* "\.php$" {
        try_files      $uri =404;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        # fastcgi_param  SCRIPT_FILENAME  $request_filename;
    }
}

Request /api/testing.php:

• $document_root$fastcgi_script_name == /app/www//api/testing.php
• $request_filename == /app/www/testing.php

Request /api/:

• $document_root$fastcgi_script_name == /app/www//api/index.php
• $request_filename == /app/www/index.php

And if you use $request_filename, you should set index using index directive, fastcgi_index will not work.

Answer 3

I guess those lines were taken from the 'fastcgi_params' file..

Basically you are not getting any errors when it comes to SCRIPT_FILENAME because it's already defined when you defined your root directive in your vhost file. So unless you defined it explicitly in your vhost file using fastcgi_param the value of SCRIPT_FILENAME would be taken from the root directive.. But ONE IMPORTANT POINT HERE. There is another variable that nginx needs in order to send the requests to the php server which is $fastcgi_script_name and you have to define it well in order to avoid repetitive URLs and errors with uri's that end with slash.

Conclusion:

To make everything work super nice, everyone should define SCRIPT_FILENAME explicitly either in 'fastcgi_params' file located in /etc/nginx folder or easily in the vhost of your site located in sites-available folder by including the following line in the php location block:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

or included in the 'fastcgi_params' file as you wrote above, either way it's the same.. For more info for connecting ngnix to PHP-FPM go to:

https://www.nginx.com/resources/wiki/start/topics/examples/phpfcgi/

I hope it would help anyone in the future 'cuz it took me a lot of time to figure it out..