file get contents возвращает пустую строку

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

  • это, по-видимому, работает. ошибок не возникло . fopen () возвращает ресурс.
  • он не возвращает данных для всех определенно работающих URL (например, http://google.com/).
    file возвращает пустой массив, file_get_contents () возвращает пустую строку, fread возвращает ложь
  • для всех намеренно неправильных 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)

7 20
php fopen

7 ответов:

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

23

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

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

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

<?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. Use 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. Попробуйте новую версию, посмотрите, сохраняется ли она в вашей системе.

13

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

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

4

Зарегистрирован ли поток http в вашей установке PHP? Ищите "зарегистрированные потоки PHP" в вашем phpinfo() выводе. На моем написано " https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip".

Если нет http, Установите allow_url_fopen в on в вашем php.ini.

2

Что вам говорит тест с fsockopen?

Изолирован ли тест от другого кода?

-1

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

Extension=php_openssl.dll

-1

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

-3