SoapClient и https отключаются с ошибкой 500 после ответа на давний вызов - PullRequest
Новая
       4

SoapClient и https отключаются с ошибкой 500 после ответа на давний вызов

0 голосов
/ 10 февраля 2020

Я провел много часов и использовал много рекомендаций, но безуспешно. это мой инициатор SoapClient: 

ini_set('default_socket_timeout', 5000);
$opts = array(
    'ssl'   => array(
        'verify_peer'       => false,
        'verify_peer_name'  => false,
        'allow_self_signed' => true
    ),
    'https' => array(
        'timeout' => 6000,
    ),
    'http'  => array(
        'timeout' => 6000,
    )
);

$options = array(
    'encoding'           => 'UTF-8',
    'verifypeer'         => false,
    'verifyhost'         => false,
    'soap_version'       => SOAP_1_2,
    'trace'              => true,
    'exceptions'         => true,
    //'timeout' => 600, // not work use this: default_socket_timeout
    'connection_timeout' => 500,
    'stream_context'     => stream_context_create($opts),
    'cache_wsdl'         => WSDL_CACHE_NONE,
    //'compression' => SOAP_COMPRESSION_ACCEPT | SOAP_COMPRESSION_GZIP | SOAP_COMPRESSION_DEFLATE | 1, //with this: Invalid XML, timeout
    //'keep_alive' => true, //true - timeout, false - timeout
);

$errors = [];

try {
    $this->_client = new \SoapClient("https://{myip}/soap?wsdl", $options);
} catch (\Exception $e) {
    $errors[] = $e->getMessage();
} catch (\Throwable $e) { // SoapClient can "Fatal Error" before it throws a SoapFault, so by catching both errors and exceptions with Throwable you will have very simple error handling
    $errors[] = $e->getMessage();
}

И мой проблемный c длинный вызов: 

try {
    $result = $this->_client->__soapCall('route',
        [$myKey, $someController, $someAction, null]);
} catch (\SoapFault $e) {
    // handle issues returned by the web service
    $errors[] = $e->getMessage();
    return false;
} catch (\Exception $e) {
    // handle PHP issues with the request
    $errors[] = $e->getMessage();
    return false;
} catch (\Throwable $e) {
    // handle rest
    $errors[] = $e->getMessage();
}

Некоторые ответы в порядке, но другой, который требует больше времени, они будут go вниз: «Внутренняя ошибка сервера» HTTP 500. И истекло время ожидания прибл. 6 - 8 секунд. Это моя серверная конфигурация всех тайм-аутов, которые я нашел: 

PHP Version 7.3.14
hard_timeout    2
ic24.api.max_timeout    7
memcache.lock_timeout   15
Read timeout    86400
default_socket_timeout  60  
opcache.force_restart_timeout   180
max_execution_time  30

Я нашел эту статью https://bugs.php.net/bug.php?id=41631, но я не уверен, исправлено ли это в PHP> = 7 И также посмотрите, что много вопросов на эту тему есть в inte rnet.

Вся проблема на рабочем сервере Linux Centos. На моем местном Xampp все в порядке. Те же конфигурации. Рабочий сервер немного отличается от Suhosin и mod_security.

Я проверил это в htaccess, чтобы отключить его: 

<IfModule mod_security.c>
  SecRuleEngine Off
  SecFilterInheritance Off
  SecFilterEngine Off
  SecFilterScanPOST Off
  SecRuleRemoveById 300015 3000016 3000017
</IfModule>

и 

php_flag suhosin.simulation On

, но не повезло .

Я пытался https://gist.github.com/RobThree/2490351, но это совсем не работает.

Я сделал еще один тест, подобный этому: 

ini_set('default_socket_timeout', -1);

И что-то изменилось. Он не ожидает ответа и без ошибок.

Журнал ошибок включен, но ошибок не регистрируется.

Рабочий сервер php -fpm и такой же, как SOAP Сервер с тот же IP.

Обновление 1:

Где-то я читал этот комментарий:

Обратите внимание, что хотя вы можете попытаться установить default_socket_timeout в что-то более 20 секунд, вы можете быть обмануты ядром Linux.

Значение по умолчанию для tcp_syn_retries установлено в 5, что эффективно сократит время ожидания любого соединения TCP примерно через 20 секунд, независимо от того, какие ограничения вы установили в * На 1070 * больше, чем это.

Значение может быть изменено только на root, например:

echo 6> / proc / sys / net / ipv4 / tcp_syn_retries

Значение 6, как указано выше, даст вам время ожидания до ~ 45 с.

Обновление 2:

Когда я вызываю тот же скрипт через cron тогда все в порядке.

...