centos+nginx+php-fpm+php include fastcgi_params php頁面能訪問但空白,被fastcgi_params與fastcgi.conf害慘了,centosnginx
今天在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 HISTORYTweetThe 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 preferfastcgi_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上加幾下注釋說明,讓粗心,沒有仔細看的我就不會這麼慘了....