centos+nginx+php-fpm+php include fastcgi_params php页面能訪问但空白,被fastcgi_params与fastcgi.conf害慘了

今天在centos上折腾这块是发现老是訪问页面时,浏览器中提示是200 ok.且訪问html后缀却是正常出现内容.

可是訪问php后缀却返回空白页面,同一时候查看全部的log没有发现不论什么出错信息;

再在nginx.conf中的server中写假设 路径不存在就return 405这种断句来调试,发现我的配置还是正常能走到那个405.

就是没有内容返回....

找了几个小时.头都快晕了.

还是没有搞明确怎么回事.

最后想想和比較了下fastcgi_params与fastcgi.conf,头已经晕了,看了几眼,没看出区别来了.

我包括的是params这个文件,不是conf这个.我就郁闷死了...怎么回事?

然后想想.是不是试试饮食一下conf这个试试看?

一改变.刷新页面,居然出来内容了...

再回头细致看眼二个文件.居然还是没发现有什么差别....已经所有晕了.

使用二个文件名称在网上查找一下,才发现,这二个文件真有差别;

并且另一个历史.

FASTCGI_PARAMS VERSUS FASTCGI.CONF – NGINX CONFIG HISTORY
Tweet
The nginx source install (and by extension package managers) includes two FastCGI configuration files, fastcgi_params and fastcgi.conf that differ only a tiny bit. To this day they still cause confusion amongst new users due to package managers.

The difference between the two files in the source install is the simple line of:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
The difference between the two files in most distributions package repositories is nothing, they essentially modified fastcgi_params to match fastcgi.conf.

What this line does is tell PHP which file it should execute, without this nginx and PHP cannot work together. This sounds like a good line to include in the shipped FastCGI configuration file and indeed Igor Sysoev thought so as well. However, due to the configurations of the time this wasn’t as easy as simply adding it in.

Back in the days of 0.6.x when I started using nginx and a few years before this change happened a typical configuration example would look like this.

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name;
    fastcgi_pass backend;
}
Due to community documentation efforts on the wiki people slowly started using the $document_root variable instead of hard coding the root path, however, many people were still using the above configuration many years later.

Because of how array directives inherit and interact the people using the old configuration style made it impossible to include the line in fastcgi_params. Doing this would have meant that SCRIPT_FILENAME would be defined twice and both would be sent to the backend, potentially causing confusing behaviour.

In 0.8.30 (released: 15th of December 2009) Igor then included fastcgi.conf which was the same as fastcgi_params except including the improved SCRIPT_FILENAME fastcgi_param. This meant that the community could now start recommending people include fastcgi.conf instead of recommending moving SCRIPT_FILENAME into fastcgi_params. New articles on the wiki mostly used this, the popular articles were slowly changed to use it and we were promoting it in the IRC support channel.

Of course, an issue back then was that package managers gave nginx very little love and were many versions behind, usually something like 0.6.x versus 0.8.x. The fastcgi.conf file was not included for these people. When they eventually did update they shipped with a fastcgi.conf and a modified fastcgi_params leaving us with a situation where the source install actually differed from the repository install in a non-significant way. While not often, this does still cause the occasional confusing in the IRC channel.

As an aside, I actually prefer

fastcgi_param SCRIPT_FILENAME $request_filename;
as it takes the alias directive into account, fastcgi_new.conf anyone?


Last updated:Sunday, July 7, 2013

关于上面的说法我理解是:

非常久非常久曾经,大家都是include fastcgi_params,并且在后面加上一句

fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name;

而nginx的开发人员慢慢发现大家写死这个root有问题.或是不方便?

于是给了一个方案,或是说,前面的时候,那块还不能写变量?

里面是硬编码写死的?

后面能够了.可是预计非常多人还是旧写法,假设直接把这句增加params这个文件的前面话,就会可能跟nginx.conf中同一时候出现,了二次.就会导致非常多莫名的问题,

有可能某些地方会用前面一个指令的路径,而还有一个地方会可能用到后面一个指令.

所以,作者保留params,新加一个文件叫fastcgi.conf.

而我却刚好理解成这二个文件是同样的...可是由于没有提供这个指令,所以,导致没有文件发送到php gate中.那么.就返回了空白内容;;;;;;;

我晕死了....几个小时........一段历史......假设在fastcgi.conf上加几下凝视说明,让粗心,没有细致看的我就不会这么慘了....