Service PHP Nginx ne pouvez pas utiliser la solution file_get_contents

I. description du problème

Un environnement de service de développement local a été construit dans un environnement Windows, utilisant Nginx pour faire le service, mais cette erreur s’est produite lorsque vous utilisiez file_get_contents () pour obtenir un lien local http://127.0.0.1/index.php :

file_get_contents(http://127.0.0.1/index.php) [<a href='function.file-get-contents'>function.file-get-contents</a>]: failed to open stream: HTTP request failed!

Environnement PHP de l’ordinateur local est : nginx + php + mysql ; donc trouver cet article de prendre une note, record !

Ces deux jours ont été engagés dans les fenêtres sous la demande de file_get_contents NGINX + FASTCGI. Je pense que beaucoup d’étudiants ont rencontré aucune pression lorsque file_get_contents demande des fichiers PHP Http/https de l’extranet, comme Echo file_get_contents (« http://www.baidu.com »), Il affichera la page de Baidu. Mais lorsque vous demandez PHP services localhost/127.0.0.1 le réseau local, c’est toujours le délai d’attente, et vous ne peut pas retourner les données, telles que file_get_contents (« http://localhost/phpinfo.php »), peu importe combien de temps vous demandera du temps et le script s’exécute. Cependant, lorsque vous essayez de télécharger un fichier statique tel que HTML, il n’est aucun problème du tout. Quelle est la raison ? !

Tout d’abord, nous savons que lorsque File_get_contents/curl/fopen ouvre une requête HTTP basé sur TCP/IP, les données de demande sont envoyées à Nginx et Nginx est déléguée à php-cgi (fastcgi) pour traiter le fichier PHP, En général, FastCGI va sortir immédiatement le signal de fin après traitement un PHP demande, attendant la prochaine demande de traitement (et, bien sûr, le programme pour simuler la mort, a pris les ressources). Nginx.conf ouvert, nous voyons la ligne suivante :

location ~ .php {        fastcgi_pass   127.0.0.1:9000;        fastcgi_index  index.php;        fastcgi_param  SCRIPT_FILENAME  d:/www/htdocs$fastcgi_script_name;        include        fastcgi_params;}

Comme il est clairement plus haut, sont de tous les fichiers qui utilisent la fin de PHP fastcgi traitée, et il y a une phrase dans le fichier de configuration php.ini :

cgi.force_redirect = 1

Indique que tous les programmes PHP forcent solidement la direction pour être remis à la transformation de CGI.

Mais sous Windows, comment est le 127.0.0.1:9000 local lié à php-cgi ? ! La réponse consiste à ajouter un processus php-cgi qui l’utilise pour écouter les 127.0.0.1:9000. Par le biais de la commande de contrôleur :

RunHiddenConsole.exe D:/www/php/php-cgi.exe  -b 127.0.0.1:9000 -c C:/WINDOWS/php.ini

Nous pouvons tourner sur un processus de php-cgi.exe pour écouter les demandes de 127.0.0.1:9000 de démarrage de Windows. Lorsque vous ouvrez netstat, une sous le commandement de DOS, vous pouvez voir que le port 9000 sous l’ordinateur local est dans état écoute (c'est-à-dire vacant si aucune demande n’est envoyé).

Eh bien, il est temps de parler de pourquoi vous ne pouvez pas retourner des résultats lorsque vous utilisez le file_get_contents (), curl (), fopen () la fonction d’accès localhost dans PHP. Nous allons essayer d’ajouter file_get_contents (« http://127.0.0.1/phpinfo.php ») à index.php. Déclaration envoie une requête à phpinfo.php, où l’indication de l’état dans le navigateur a été de filature, indiquant qu’il travaille. Ouvrez la commande netstat sous Dos et vous pouvez voir que l’état du port 9000 local est : mis en place, ce qui indique que le processus est en traitement en ligne. En effet, ici nous avons envoyé deux requêtes PHP basé sur HTTP pour nginx dans le même temps, L’un est l’analyse index.php, et l’autre est phpinfo.php, ainsi, la contradiction vient, parce que notre système de windows ne charge pas un seul processus HTTP, afin qu’il ne peut pas gérer deux requêtes PHP dans le même temps, il ne peut traiter que la première demande (index.php) et index.php Alors que l’attente pour phpinfo.php à traiter le résultat, phpinfo.php ne lui permet de traiter la demande parce qu’elle attend depuis index.php libérer le signal de fin, causant ainsi le programme à bloquer l’état et tomber dans une boucle de morte. Donc, nous avons vu que l’état du navigateur indique qu’il tournait tout le temps. Curl () a la même raison que la fonction fopen.

II. les Solutions

Si nous trouvons la raison pour laquelle, nous avons une solution.

On doit ajouter une requête HTTP vers le système qui peut renvoyer des demandes supplémentaires de PHP autre HTTP traitement lorsqu’une autre demande est chargée dans un php-cig. À ce stade, vous devez affecter un autre port http un autre serveur, comme 8080. Le cas de Nginx est comme suit :

http {      server {          listen          80;          server_name     127.0.0.1;          location / {              index index.php;              root  /web/www/htdocs;          }      }      server {          listen          8080;          server_name     127.0.0.1;          location / {              index index.html;              root  /web/www/htdocs;          }      }      include    /opt/nginx/conf/vhosts/php.conf;  }

De cette façon, les ports 80 et 8080 peuvent gérer différents programmes séparément, telles que :
Test.php

 echo file_get_contents('http://localhost:8080/phpinfo.php');

Bien sûr, il y a plus d’options sous * unix, tels que de la fourche.

En outre, certaines personnes sur l’internet a déclaré qu’en supprimant l’adresse de la balise http://protocol et l’utilisation de l’adresse relative sur le contournement de la fonction de contrôle, la réalité n’est pas alors ? ! Lorsque file_get_contents (« phpinfo.php ») est utilisé dans index.php ; , Nous pouvons voir que la fonction renvoie le code source de phpinfo.php, ce qui équivaut à file_get_contents (« file:c:wwwphpinfo.php ») ; , Il lit en fait juste le contenu de votre texte, car la fonction file_get_contents gère tout d’abord le protocole file, alors que courbure directement les erreurs ne peuvent être résolus. Si ces gens sont des menteurs purement ignorants.

Il a également été proposé d’amender le document d’hôtes pour ajouter localhost Relation d’insinuations www.xxx.com, fonctionnent par l’intermédiaire de l’accès www.xxx.com pour le PHP local, qui est en fait pas un remède, parce que cela n’est pas pratique pour l’ordinateur DNS l’analyse, la finale www.xxx.com à 127.0.0.1 et le second pour le HTTP uniquement, ou le blocage.

Recommandations y afférentes :

Solution de contournement qui ne pouvez pas utiliser la fonction file_get_contents

Comment PHP se connecte au serveur Nginx et résout le journal Nginx