file_get_contents возвращает пустую строку

Я не решаюсь задавать этот вопрос, потому что это выглядит странно. Но в любом случае. На всякий случай кто-то столкнулся с той же проблемой … функции файловой системы (fopem, file, file_get_contents) ведут себя очень странно для http: // wrapper

  • это, похоже, работает. ошибок не было . fopen () возвращает ресурс.
  • он не возвращает данные для всех конечно работающих URL-адресов (например, http://google.com/ ).
    file возвращает пустой массив, file_get_contents () возвращает пустую строку, fread возвращает false
  • для всех намеренно неправильных URL-адресов (например, http://goog973jd23le.com/ ) он ведет себя точно так же, за исключением небольшого таймаута [предположительно, для домена], после чего я не получаю ошибки (пока должен!), а пустой строки.
  • url_fopen_wrapper включен
  • curl (как для командной строки, так и для php-версий) отлично работает, все остальные утилиты и приложения работают нормально, локальные файлы открываются нормально

Эта ошибка кажется неприменимой, потому что в моем случае она не работает для каждого URL-адреса или хоста.

php-fpm 5.2.11 Linux версия 2.6.35.6-48.fc14.i686 (mockbuild@x86-18.phx2.fedoraproject.org)

Related of "file_get_contents возвращает пустую строку"

Я исправил эту проблему на своем сервере (запустив PHP 5.3.3 на Fedora 14), удалив -with-curlwrapper из конфигурации PHP и перестроил его.

Звучит как ошибка. Но только для потомков, вот несколько вещей, которые вы, возможно, захотите отладить.

  • allow_url_fopen : уже проверено
  • PHP под Apache может вести себя иначе, чем PHP-CLI, и намекнул бы на chroot / selinux / fastcgi / etc. ограничения безопасности
  • локальный брандмауэр: маловероятно, так как curl works
  • блокировка пользовательского агента: это довольно часто, сайты блокируют сканеры и неизвестные клиенты
  • прозрачный прокси от вашего интернет-провайдера, который либо искажает, либо блокирует (пользовательский агент PHP или не-пользователь-агент может быть интерпретирован как вредоносное ПО)
  • Проблемы с оболочкой PHP-потока

В любом случае, сначала давайте докажем, что обработчики потоков PHP являются функциональными:

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

Затем попробуйте посмотреть, действительно ли PHP делает реальные HTTP-запросы. Сначала откройте netcat на консоли:

 nc -l 80000 

И отлаживать с помощью:

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

И здесь вы можете попытаться установить связь с PHP, посмотреть, вернется ли что-то, если вы измените ответ. Сначала введите недействительный ответ в netcat. Если нет ошибки, ваш пакет PHP будет обработан.

(Возможно, вы также попытаетесь связаться с дескриптором «tcp: // ..».)

Затем мы экспериментируем с параметрами оболочки HTTP-потока. Используйте http://example.com/ буквально, который, как известно, работает и никогда не блокирует пользовательские агенты.

 $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); 

Я думаю, что ignore_errors здесь очень уместен. Но проверьте http://www.php.net/manual/en/context.http.php и, в частности, попробуйте установить protocol_version в 1.1 (получите ответ и неверно интерпретированный ответ, но по крайней мере мы увидим, что что-то вернется).

Если даже это не удастся, попробуйте взломать http-обертку.

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

Это не только установит User-Agent, но и добавит дополнительные заголовки. Если есть проблема с обработкой при построении запроса в оболочке HTTP-потока, то это может в конечном итоге ее уловить.

В противном случае попытайтесь отключить любые расширения Zend, Suhosin , PHP xdebug, APC и другие базовые модули. Там могут быть помехи. Иначе это потенциально проблема, относящаяся к пакету Fedora. Попробуйте новую версию, посмотрите, сохраняется ли она в вашей системе.

Когда вы используете оболочку HTTP-потока, PHP создает массив для вас, называемый $ http_response_header после того, как вызывается file_get_contents () (или любое другое семейство функций f). Это содержит полезную информацию о состоянии ответа. Не могли бы вы сделать var_dump () этого массива и посмотреть, дает ли он вам больше информации об ответе?

Это странная ошибка, которую вы получаете. Единственное, о чем я могу думать, это то, что что-то еще на сервере блокирует HTTP-запросы от PHP, но потом я не понимаю, почему cURL все равно будет в порядке …

Является ли HTTP-поток зарегистрированным в вашей установке PHP? Ищите «Зарегистрированные потоки PHP» в вашем phpinfo (). Mine говорит: «https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip».

Если нет http, установите allow_url_fopen на свой php.ini.

Что скажет вам тест fsockopen ?

Является ли тест изолированным от другого кода?

У меня была такая же проблема в Windows после установки XAMPP 1.7.7. В конце концов мне удалось решить эту проблему, добавив следующую строку в php.ini (имея allow_url_fopen = On):

расширение = php_openssl.dll

Используйте http://pear.php.net/reference/PHP_Compat-latest/__filesource/fsource_PHP_Compat__PHP_Compat-1.6.0a2CompatFunctionfile_get_contents.php.html и переименуйте его и проверьте, произошла ли ошибка с этой перезаписанной функцией.