file_get_contents devuelve cadena vacía

Question

Tengo dudas en hacer esta pregunta porque se ve raro. Pero de todos modos. Sólo en caso de que alguien se había encontrado con el mismo problema ya ... funciones del sistema de archivos (fopem, archivos, file_get_contents) se comportan muy extraño para http: // wrapper

• que aparentemente funciona. no hay errores planteados. fopen() devuelve el recurso.
• no devuelve datos para todas las URL que funcionan (por ejemplo, http://google.com/).
  archivo vuelve matriz vacía, file_get_contents() devuelve una cadena vacía, fread devuelve falso
• para todas las URLs intencionadamente erróneos (por ejemplo http://goog973jd23le.com/) se comporta exactamente igual, salvo por poco [de búsqueda supuestamente dominio] de tiempo de espera, después de lo cual me sale error (¡pero debería!) pero cadena vacía.
• url_fopen_wrapper se enciende
• rizo (tanto en la línea de comandos y las versiones de PHP) funciona bien, todas las otras utilidades y aplicaciones de obras, archivos locales finas abrieron bien

This error parece inaplicable porque en mi caso no funciona para cada url o host.

php-FPM 5.2.11 Linux versión 2.6.35.6-48.fc14.i686 (mockbuild@x86-18.phx2.fedoraproject.org)

Answer 1

Solucioné este problema en mi servidor (ejecutando PHP 5.3.3 en Fedora 14) eliminando --with-curlwrapper de la configuración de PHP y reconstruyéndolo.

Answer 2

Cuando se utiliza el PHP http corriente envoltorio crea una matriz para usted llamó $http_response_header después de file_get_contents() (o cualquiera de la otra f familia de funciones) se llama. Esto contiene información útil sobre el estado de la respuesta. ¿Podría hacer un var_dump() de esta matriz y ver si le da más información sobre la respuesta?

Es un error realmente extraño que está recibiendo. Lo único que se me ocurre es que algo más en el servidor está bloqueando las solicitudes http de PHP, pero entonces no puedo ver por qué cURL todavía estaría bien ...

Answer 3

Se ha registrado http en tu instalación de PHP ? Busque "Flujos PHP registrados" en su salida phpinfo(). El mío dice "https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip".

Si no hay http, configure allow_url_fopen en su php.ini.

Answer 4

Use http://pear.php.net/reference/PHP_Compat-latest/__filesource/fsource_PHP_Compat__PHP_Compat-1.6.0a2CompatFunctionfile_get_contents.php.html y cámbiele el nombre y compruebe si el error ocurre con esta función reescrita.

Answer 5

¿Qué le dice una prueba con fsockopen?

¿La prueba está aislada de otro código?

Answer 6

Suena como un error. Pero solo para la posteridad, aquí hay algunas cosas que quizás desee depurar.

• allow_url_fopen: Ya se han probado
• PHP bajo Apache podría comportarse de manera diferente a PHP-CLI y sería insinuar/fastcgi/chroot/selinux etc.restricciones de seguridad
• servidor de seguridad local: rizo poco probable ya que funciona
• usuario-agente de bloqueo: Esto es bastante común en realidad, sitios web de bloque rastreadores y clientes desconocidos
• proxy transparente de su ISP, que o bien mangles o bloques (PHP por el usuario agente o no de agente de usuario podría interpretarse como malware)
• problemas envoltura de secuencia PHP

de todos modos, primero nos dejó una prueba de que los controladores de flujo phps son funcionales:

<?php 
    if (!file_get_contents("data:,ok")) { 
      die("Houston, we have a stream wrapper problem."); 
    } 

A continuación, intente ver si PHP realiza solicitudes HTTP reales. netcat abre por primera vez en la consola:

nc -l 80000 

y depurar con sólo:

<?php 
    print file_get_contents("http://localhost:8000/hello"); 

Y a partir de aquí se puede tratar de comunicarse con PHP, ver si hay algo devuelve si la respuesta variable aleatoria. Ingrese una respuesta no válida primero en netcat. Si no se produce ningún error, su paquete de PHP está borked.

(También puede tratar de comunicarse a través de un "tcp: // .." manejar a continuación.)

Lo siguiente está experimentando con los parámetros de envoltura de flujo HTTP. Use http://example.com/ literalmente, que se sabe que funciona y nunca bloquea a los usuarios-agentes.

$context = stream_context_create(array("http"=>array(
    "method" => "GET", 
    "header" => "Accept: xml/*, text/*, */*\r\n", 
    "ignore_errors" => false, 
    "timeout" => 50, 
)); 

print file_get_contents("http://www.example.com/", false, $context, 0, 1000); 

creo ignore_errors es muy relevante aquí. Pero mira http://www.php.net/manual/en/context.http.php y específicamente intenta configurar protocol_version a 1.1 (obtendrá una respuesta fragmentada y mal interpretada, pero al menos veremos si cualquier cosa regresa).

Si incluso esto sigue sin éxito, intente hackear el envoltorio http.

<?php 
    ini_set("user_agent" , "Mozilla/3.0\r\nAccept: */*\r\nX-Padding: Foo"); 

Esto no solo configurará el User-Agent, sino que inyectará encabezados adicionales. Si hay un problema de procesamiento con la construcción de la solicitud dentro de la envoltura de flujo http, entonces esto podría muy eventualmente atraparlo.

De lo contrario, intente desactivar las extensiones de Zend, Suhosin, PHP xdebug, APC y otros módulos principales. Podría haber interferencias. De lo contrario, este es potencialmente un problema específico del paquete de Fedora. Pruebe una nueva versión, vea si persiste en su sistema.

Answer 7

Tuve el mismo problema en Windows después de instalar XAMPP 1.7.7. Con el tiempo me las arreglé para resolver añadiendo la siguiente línea a php.ini (mientras que allow_url_fopen = On):

extensión = php_openssl.dll