Статус HTTP запроса

Аватар пользователя alexey78 alexey78 23 марта 2008 в 11:38

С недавнего времени в "Отчете о состоянии" - Статус HTTP запроса = неудача (Ваша системная или сетевая конфигурация не позволяет Drupal обращаться к веб-страницам, что выражается в ограниченной функциональности. Это может происходить из-за настроек PHP и должно быть исправлено для получения информации о доступных обновлениях, сбора новостей из RSS-лент, входа по OpenID и для использования других сетевых сервисов).

В php.ini не лазил... до этого все работало... другие сайты на 6-ом друпале на этом же хостинге работают нормально... что делать? Sad

Комментарии

Аватар пользователя mgk mgk 10 июня 2008 в 10:56

сегодня появилась такаяже ошибка...
мож кто подскажет в чем проблема друпал 6.2
появилась после установки модуля taxonomy_menu причем насколько я понял версия модуля для drupal 6.1

похоже друпал ищет обновления и там где они должны быть их ненаходит(

Аватар пользователя Lvl Lvl 16 июня 2008 в 12:24

Скорее всего хостер запретил обращение к внешним ссылкам из скриптов.
Можно попробовать простенький скрипт: echo file_get_contents('http://yandex.ru');
если будет пустой экран или ошибка, значит запрещено.

Аватар пользователя Equ Equ 15 июля 2008 в 0:46

Недавно тоже заметил такую проблему. На хостинге allow_url_fopen включен. Что делать?

Аватар пользователя Speakus Speakus 24 ноября 2008 в 4:09

столкнулся с такой проблемой на 6.6 .
echo file_get_contents('http://yandex.ru');
работает без проблем - видимо drupal использует какой-то другой механизм получения содержимого...
upd:
на хостинге отключена функция fsockopen() - соответсвенно проблемы из-за этого

Аватар пользователя Zhitkov Alex Zhitkov Alex 5 января 2009 в 6:28

Если на Вашем хостинге "по умолчанию" отключена функция fsockopen() ...

1. Узнаем про такое "отключение" у Вашего хостера
2. Пишем свой файлик php.ini такого содержания:
(строки, которые начинаются со знака ; можно не писать Smile

[PHP]
; Этот файл подключает функцию fsockopen для корректной работы DRUPAL с
; сокетами (обновлениями, RSS и другими сетевыми службами).
; Этот файл необходимо разместить в каталоге, где установлен "капризный"
; скрипт (тот скрипт, который не хочет работать с php.ini "по умолчанию").
; Необходимые для работы такого скрипта настройки будут взяты из этого
; файла, а прочие настройки и директивы будут взяты из php.ini,
; установленного на Вашем хостинге "по умолчанию".
; ОБРАТИТЕ ВНИМАНИЕ!
; Этот файл не "наследуется" в нижележащие каталоги Вашего скрипта (как,
; например, директивы файла .htaccess).
; Поэтому надо в каждый из каталогов Вашего скрипта поместить этот файлик
; (если только Ваш "капризный" скрипт расположен в нескольких каталогах.

; This directive allows you to disable certain functions for security
; reasons.
; It receives a comma-delimited list of function names. This directive is
; *NOT* affected by whether Safe Mode is turned On or Off.

disable_functions = exec, popen, passthru, system, shell_exec, virtual, proc_close, proc_get_status, proc_open, proc_terminate

; << Конец файла >>

3. Размещаем этот файлик в каталоге "капризного" скрипта - в случае DRUPAL - в корневом каталоге DRUPALа.
4. Выходим из "админки" DRUPALа и заходим вновь - ошибка "Статус HTTP запроса = неудача" больше не возникает.

Аватар пользователя andypost@drupal.org andypost@drupal.org 7 января 2009 в 1:38

прошли изменения в 6-dev http://drupal.org/node/245990

Теперь проверяется на доступность example.com и выдается сообщение, что нет связи с внешним миром, хотя проблема как правило действительно в настройках php или недоступности опрашиваемых сайтов

Аватар пользователя uZzbek uZzbek 20 февраля 2009 в 16:19

ну так и что? кто-то понял в чем проблема и как она решается? Smile
у меня из-за этого видимо даже админка тупить начала, и я вместе с ней Smile

Аватар пользователя uZzbek uZzbek 20 февраля 2009 в 16:33

отвечу сам себе - пошарился по исходным кодам - нашёл файлик modules/system/system.module

там нашёл функцию:
function system_check_http_request() {
лалалала...тут всякий хитрый код который вызывает другой хитрый код...
}

закоментил всё её содержимое
и добавил return 1

получилось:
function system_check_http_request() {
/*
лалалала...тут всякий хитрый код который вызывает другой хитрый код...
*/
return 1;
}

наверное это не очень хорошее решение, но если кто-то исправит багу, я конечно всё верну на место Biggrin

а пока - вроде перестало ругаться, вот и хорошо Smile

Аватар пользователя rbogdan@drupal.org rbogdan@drupal.org 16 марта 2009 в 12:32

Была та же самая проблема, на хостинге rss не работала на 6.9, но работала на 6.4.
Пришлось для 6.9 использовать модуль 6.4 и includes/common.inc заменить функции для rss.
Все заработало, не было времени разбираться в чем именно дело, и из-за чего возникли проблемы в более поздних версиях.
Может кто-нибудь более детально рассмотрит проблему, так как это не единичные случаи.

Последние заплаты в работу rss на drupal.org не приводят к положительному результату.

Аватар пользователя erbol erbol 19 марта 2009 в 17:51

В моем случае проблема была в настройках днс сервера.

Объясню по порядку:
залез в файл includes/common.inc там дальше нашел функцию запроса хттп:
function drupal_http_request()
далее, там есть строчка $fp = fsockopen($uri['host'], $port, $errno, $errstr, 15);
так вот, если убрать заглушку (символ "@" перед fsockopen), то при обновлении Отчета о состоянии, должна появиться ошибка, в моем случае была следующая ошибка:
* warning: fsockopen() [function.fsockopen]: php_network_getaddresses: getaddrinfo failed: hostname nor servname provided, or not known in /includes/common.inc on line 436.
* warning: fsockopen() [function.fsockopen]: unable to connect to test.myhost.kz:80 (php_network_getaddresses: getaddrinfo failed: hostname nor servname provided, or not known) in /includes/common.inc on line 436.
(После не забываем вернуть заглушку на место)

т.е. здесь говорится что не получается найти хост test.myhost.kz:80 (кстати на нем же и стоит drupal), добавил следующую запись в etc/hosts :
127.0.0.1 test.myhost.kz
и проблема решилась.
Если у Вас хостинг, тогда ищите настройки днс сервера на Вашей панели, а то как правильно настраивать сервер named , думаю это уже другая тема

Аватар пользователя sadad sadad 4 февраля 2011 в 18:39

erbol wrote:
В моем случае проблема была в настройках днс сервера.

не получается найти хост test.myhost.kz:80 (кстати на нем же и стоит drupal), добавил следующую запись в etc/hosts :
127.0.0.1 test.myhost.kz
и проблема решилась.
Если у Вас хостинг, тогда ищите настройки днс сервера на Вашей панели, а то как правильно настраивать сервер named , думаю это уже другая тема

Именно так!

Аватар пользователя Daemony@drupal.org Daemony@drupal.org 4 июня 2009 в 15:41

Однозначно проблема в DNS.
Если тестировать Drupal на тестовом сайте, с вымышленным доменным именем (которое в DNS не прописано), тоже будет вылазить эта ошибка, потому что, видимо, движок пытается понять кто он такой и не может этого сделать, не может отрезолвить свое имя. Вот только зачем он это делает, мне непонятно...

Аватар пользователя SVictor SVictor 22 октября 2009 в 14:33

Именно это изменение в php.ini помогло, спасибо.

"Zhitkov Alex" wrote:
disable_functions = exec, popen, passthru, system, shell_exec, virtual, proc_close, proc_get_status, proc_open, proc_terminate

Аватар пользователя SuperXren SuperXren 27 марта 2010 в 2:21

Именно это изменение в php.ini помогло, спасибо.
"Zhitkov Alex" написал(а):

disable_functions = exec, popen, passthru, system, shell_exec, virtual, proc_close, proc_get_status, proc_open, proc_terminate

А куда ты бросал этот файл ?

Аватар пользователя Softovick Softovick 13 августа 2010 в 21:35

Друзья, тоже столкнулся с такой проблемой, но решилось все просто - так как тестировалось на тестовом сервере на вымышленном домене, то достаточно было в hosts прописать ip-адрес и имя хоста.

Аватар пользователя sadad sadad 25 ноября 2010 в 2:18

Хорошо-то как, когда есть drupal.ru!!! Даже разбираться не пришлось с такой же проблемой. Здесь все ответы нашел Smile

Аватар пользователя llirikks llirikks 28 ноября 2010 в 21:20

Аналогичная проблема только что создал домен, прописал DNS своего mini server. Установил на него Drupal 6.х доступ к сайту происходил путем редактирования файла c:\windows\system32\drivers\etc\hosts в Windows 7, с указанием прямого IP сервера, прочитал этот топик, как результат не предпринимал нечего просто ждал, после включения (обновления) DNS ошибка исчезла сама по себе, что и следовало ожидать. Ура товарищи на 1 Drupal в интернете стало больше!

Аватар пользователя tlito tlito 19 ноября 2015 в 13:34

у меня впс. и я до сих пор не знаю как правильно настроить хост. и в частности эта проблема повторяется у меня. предложенная функция file_get_content с внешним урл не работает. ретарт нгинкс не помог.
что делать?

Аватар пользователя dashiwa dashiwa 19 ноября 2015 в 13:44

Днс-ы проверить надо,у меня на хостинге часто отваливается доступ к зарубежным сервакам а иногда днс шалит,не знаю с чем связано сам днс-сы не поднимал ,говорят это геморойное дело

Аватар пользователя tlito tlito 19 ноября 2015 в 14:04

vps на сервере time4vps. там кажется tier http://hosting101.ru/time4vps.eu.
я вчера пытался поставить bind9 и наверное я там отключил внешние урл. доставить ns так и не получилось тем более у меня 1 ip. а сломать сломал.
настройки /etc/bind/named.conf.options вот http://itmages.ru/image/view/3216461/d46f1d05
что делать?

Аватар пользователя tlito tlito 19 ноября 2015 в 16:31

на латинском домене ситуация не повторяется. то есть один и тот же друпал работает с двумя доменами: латинским и кириллическим. так вот на кириллическом проблема есть и в отчетах видно. а на латинском домене проблемы нет, и в отчетах не отражено.
как раз хотел смотреть перевод, чтобы задать вопрос на английском. но оказалось один и тот же друпал отчеты делает для двух доменов свои. подскажите как мне правильно настроить IDN-домен? мой конфиг такой:

# cat /etc/nginx/sites-available/xn--d1aejaxb1a.xn--p1ai
server {
    listen                  80;
    server_name             www.xn--d1aejaxb1a.xn--p1ai xn--d1aejaxb1a.xn--p1ai;
 
    set                     $main_host          'xn--d1aejaxb1a.xn--p1ai';
 
    if ($host != $main_host) {
        rewrite             ^(.*)$              http://$main_host$1     permanent;
        break;
    }
 
    access_log              /var/log/nginx/xn--d1aejaxb1a.xn--p1ai.access.log;
    error_log               /var/log/nginx/xn--d1aejaxb1a.xn--p1ai.error.log;
 
    root                    /var/www/$main_host/www;
    index                   index.php index.html index.htm;
 
    location / {
        try_files           $uri    $uri/    /index.php?$args;
    }  
 
    location ~ \.php$ {
        include             /etc/nginx/conf.d/fastcgi_params.conf;
 
        fastcgi_param       SCRIPT_FILENAME     /var/www/$main_host/www$fastcgi_script_name;
        fastcgi_param       DOCUMENT_ROOT       /var/www/$main_host/www;
 
        fastcgi_param       PHP_ADMIN_VALUE     upload_tmp_dir=/var/www/$main_host/tmp/upload;
        fastcgi_param       PHP_ADMIN_VALUE     session.save_path=/var/www/$main_host/tmp/sessions;
    }
 
    location ~ /\. {
        deny                all;
        access_log          off;
        log_not_found       off;
    }
}

это в конфиге хоста дело или в чем?