centos+nginx+php-fpm+php include fastcgi_params PHP page to access but blank, was fastcgi_params and fastcgi.conf harm dire

Today, in CentOS, this is the discovery of constant access to the page, the browser prompt is OK. and access to the HTML suffix is the normal appearance of the content.

However, access to the PHP suffix is returned to a blank page, the same time to view all the log did not find any error messages;

Again in the nginx.conf in the server write the assumption path does not exist on the return 405 this kind of segmentation to debug, found that my configuration or normal can go to that 405.

Just no content to return ....

For a few hours. The head was almost dizzy.

It's still not clear what's going on.

Finally think and compare the next Fastcgi_params and Fastcgi.conf, the head has been dizzy, looked at a few eyes, did not see the difference.

I include the params file, not conf. I'm depressed and dead. What's going on?

And think about it. Do you want to try a diet conf this?

A change. Refresh the page, incredibly out of the content ...

And look at the eyes two files. I still don't see any difference .... It's all dizzy.

Use two file name on the Internet to find out, only to find that these two files are really different;

and another history.

Fastcgi_params VERSUS FASTCGI. Conf–nginx CONFIG historytweetthe NGINX Source Install (and by extension package managers) includes, FastCGI Configur ation files, Fastcgi_params and fastcgi.conf that differ only a tiny bit. To the They still cause confusion amongst new users due to the package managers. The difference between the both files in the source install are the simple line Of:fastcgi_param script_filename $document _r Oot$fastcgi_script_name; The difference between the "the" and the "distributions" package repositories are nothing, they essentially modified fast Cgi_params to match Fastcgi.conf.What this line does are 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 wel L. 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 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 arrays directives inherit and interact the people using the old configuration style made it impossible Clude the line in Fastcgi_params.  Doing This would has meant that Script_filename would be defined twice and both would is sent to the backend, potentially causing confusing behaviour. In 0.8.30 (released:15th of December) Igor then included fastcgi.conf which is the same as Fastcgi_params except in Cluding the improved Script_filename fastcgi_param. This meant, 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-then-was, the 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 is not included for these people.  When they eventually do update they shipped with a fastcgi.conf and a modified fastcgi_params leaving us with a situation Where the source is install actually differed from the repository install in a non-significant. While isn't 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 to account , fastcgi_new.conf anyone?
Last Updated:sunday, July 7, 2013

I understand that the above statement is:

Very long, long time ago, everyone is include fastcgi_params, and in the back add a sentence

Fastcgi_param Script_filename/var/www/foo$fastcgi_script_name;

Since this directive is an array-shape, it does not say that the same name will replace the previous one.

And nginx developers slowly found that everyone wrote dead this root has a problem. or inconvenient?

So given a plan, or, in the front, that block can not write variables?

The inside is hard coded to write dead?

We can do it later. However, it is expected that very many people are still old, assuming that by adding the params directly to the previous word of this file, it may appear at the same time as nginx.conf, two times. It can cause a lot of inexplicable problems,

It is possible that some places will use the path of the previous command, and there is a place where the latter instruction may be used.

So, the author retains the params, and the new file is called fastcgi.conf.

And I just happen to understand that these two files are the same ... However, since this command was not provided, no files were sent to the PHP gate. Then, the blank content was returned;;;;;;;

I was dizzy .... A few hours ... A period of history ... Suppose to add a few stares on the fastcgi.conf, let careless, do not look carefully I will not be so dire ....

centos+nginx+php-fpm+php include fastcgi_params PHP page to access but blank, was fastcgi_params and fastcgi.conf harm dire