file_get_contents example empty ejemplos php fopen

example - file_get_contents(''php://input'');



file_get_contents devuelve una cadena vacía (7)

Tengo dudas para hacer esta pregunta porque se ve raro. Pero de todos modos. En caso de que alguien ya haya encontrado el mismo problema ... las funciones del sistema de archivos (fopem, file, file_get_contents) se comportan de manera muy extraña para http: // wrapper

  • Aparentemente funciona. no hay errores planteados . fopen () devuelve el recurso.
  • no devuelve datos para todas las direcciones URL que funcionan (por ejemplo, http://google.com/ ).
    el archivo devuelve una matriz vacía, file_get_contents () devuelve una cadena vacía, fread devuelve falso
  • para todas las direcciones URL intencionalmente incorrectas (p. ej., http://goog973jd23le.com/ ) se comporta exactamente igual, excepto por un pequeño tiempo de espera (supuestamente búsqueda de dominio), después del cual no aparece ningún error (¡mientras debería!) sino una cadena vacía.
  • url_fopen_wrapper está activado
  • curl (tanto la línea de comandos como las versiones php) funciona bien, todas las demás utilidades y aplicaciones funcionan bien, los archivos locales se abrieron bien

Este error parece inaplicable porque en mi caso no funciona para todas las direcciones URL o host.

php-fpm 5.2.11 Linux versión 2.6.35.6-48.fc14.i686 ([email protected])

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

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

¿Qué te dice una prueba con fsockopen ?

¿Está la prueba aislada de otro código?

Cuando utiliza la envoltura de flujo de http, PHP crea una matriz llamada $http_response_header después de $http_response_header file_get_contents() (o cualquiera de las otras f familias de funciones). 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ás recibiendo. Lo único en lo que puedo pensar es que algo más en el servidor está bloqueando las solicitudes http de PHP, pero luego no puedo ver por qué cURL aún estaría bien ...

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

Suena como un error. Pero solo para la posteridad, aquí hay algunas cosas que tal vez quiera depurar.

  • allow_url_fopen : ya probado
  • PHP bajo Apache podría comportarse de manera diferente a PHP-CLI, e insinuar chroot / selinux / fastcgi / etc. restricciones de seguridad
  • Cortafuegos local: poco probable ya que el rizo funciona
  • bloqueo de agente de usuario: esto es bastante común en realidad, los sitios web bloquean rastreadores y clientes desconocidos
  • proxy transparente de su ISP, que puede ser gestionado o bloqueado (PHP user-agent o no-user-agent podría interpretarse como malware)
  • Problemas con la envoltura de secuencias de PHP

De todos modos, primero comprobemos que los controladores de flujo de PHP 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 en absoluto. Primero abre el netcat en la consola:

nc -l 80000

Y depurar con solo:

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

Y desde aquí puedes intentar comunicarte con PHP, ver si algo regresa si varia la respuesta. Ingrese una respuesta inválida primero en netcat. Si no se produce ningún error, tu paquete de PHP está bloqueado.

(También puede intentar comunicarse a través de un identificador "tcp: // .." entonces).

Lo siguiente es experimentar con los parámetros de envoltura de la secuencia http. Use http://example.com/ literalmente, que se sabe que funciona y nunca bloquea a los agentes de usuario.

$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 que ignore_errors es muy relevante aquí. Pero visite http://www.php.net/manual/en/context.http.php y, específicamente, intente configurar la versión_protección del protocol_version a 1.1 (obtendrá una respuesta fragmentada y malinterpretada, pero al menos veremos si algo vuelve).

Si incluso esto no tiene éxito, intente hackear el contenedor http.

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

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

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

Tuve el mismo problema en Windows después de instalar XAMPP 1.7.7. Finalmente, logré resolverlo agregando la siguiente línea a php.ini (mientras tenía allow_url_fopen = On):

extension = php_openssl.dll