Guzzle curl error 52 empty reply from server

Hello, I was hoping someone could shed some light on an error which I am receiving. This is my code: $client = new GuzzleHttpClient(); $response = $client->post( $url, [ 'exceptions' =...

I’m having the same error when sending a file larger than 1MB. Using version 6.3.2.
My code:

$client = new GuzzleHttpClient();
$options = [
    'multipart' => [
        [
            'name'     => 'files[]',
            'contents' => fopen('/path/to/file/larger/1MB.ext', 'r'), // or many files, the size of which together exceeds 1MB
        ],
    ]
];
$response = $client->request('POST', 'http://url.local', $options);

Full stack:

[GuzzleHttpExceptionConnectException] 
cURL error 52: Empty reply from server (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) (0)
/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:185
#0: GuzzleHttpHandlerCurlFactory::createRejection(object, array)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:149
#1: GuzzleHttpHandlerCurlFactory::finishError(object, object, object)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:102
#2: GuzzleHttpHandlerCurlFactory::finish(object, object, object)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php:43
#3: GuzzleHttpHandlerCurlHandler->__invoke(object, array)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php:28
#4: GuzzleHttpHandlerProxy::GuzzleHttpHandler{closure}(object, array)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php:51
#5: GuzzleHttpHandlerProxy::GuzzleHttpHandler{closure}(object, array)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php:66
#6: GuzzleHttpPrepareBodyMiddleware->__invoke(object, array)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Middleware.php:30
#7: GuzzleHttpMiddleware::GuzzleHttp{closure}(object, array)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/RedirectMiddleware.php:70
#8: GuzzleHttpRedirectMiddleware->__invoke(object, array)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Middleware.php:60
#9: GuzzleHttpMiddleware::GuzzleHttp{closure}(object, array)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/HandlerStack.php:67
#10: GuzzleHttpHandlerStack->__invoke(object, array)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Client.php:277
#11: GuzzleHttpClient->transfer(object, array)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Client.php:125
#12: GuzzleHttpClient->requestAsync(string, string, array)
	/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Client.php:131
#13: GuzzleHttpClient->request(string, string, array)
	/var/www/bitrix/test.php:40

Reason for that line 253 of class GuzzleHttpHandlerCurlFactory, method CurlFactory::applyBody() https://github.com/guzzle/guzzle/blob/6.3.2/src/Handler/CurlFactory.php#L253

Temporarily solved the problem by adding header ‘Content-Length:1’ by the request:

$client = new GuzzleHttpClient();
$options = [
    // this header value is deceives this condition https://github.com/guzzle/guzzle/blob/6.3.2/src/Handler/CurlFactory.php#L253
    'headers' => [
        'Content-Length' => 1
    ],
    'multipart' => [
        [
            'name'     => 'files[]',
            'contents' => fopen('/path/to/file/larger/1MB.ext', 'r'), // or many files, the size of which together exceeds 1MB
        ],
    ]
];
$response = $client->request('POST', 'http://url.local', $options);

But I don’t think it’s the right thing to do. Does anyone know why this behavior occurs?

P.S. Naked curl works well:

$pathToBigFile = '/path/to/file/larger/1MB.ext';

$postdata = array(
    'file' => new CURLFile($pathToBigFile, null, basename($pathToBigFile)),
);

if( $curl = curl_init() ) {
    curl_setopt($curl, CURLOPT_URL, 'http://url.local');
    curl_setopt($curl, CURLOPT_RETURNTRANSFER,true);
    curl_setopt($curl, CURLOPT_POST, true);
    curl_setopt($curl, CURLOPT_POSTFIELDS, $postdata);
    curl_setopt($curl,CURLOPT_ENCODING, '');
    $out = curl_exec($curl);
    curl_close($curl);
}
Источник

curl (52) empty reply from server occurs when the libcurl didn’t receive any response from the server after it sent off its request.

Here at Bobcares, we have seen several such curl related issues as part of our Server Management Services for web hosts and online service providers.

Today we’ll take a look at the cause for this error and how to fix it.

Know more about curl (52) empty reply from server

The error “empty reply from server” indicates that a zero-length response was received. This means no HTTP headers or content, simply a closed TCP connection with no HTTP payload is transmitted.

curl: (52) Empty reply from the server is a server related issue. However, this happens when libcurl did not receive any response from the server even after it has sent off its request.

For instance, the error appears as below.

curl (52) empty reply from server

Here, we need to troubleshoot this error from the server-side and not from the client-side. Also, ‘Empty response’ is different from ‘no response’. Empty response means you are getting a reply that does not contain any data.

Causes and Fixes for curl (52) empty reply from server

Now, let’s discuss the different causes and fixes provided by our Support Engineers.

1. Cause: Using a very old version of libcurl

Fix: In this case, we suggest customers upgrade the version of libcurl

2. Cause: Something in the network/setup is preventing this from working, like a firewall.

Fix: We check the firewall rules and ensure that HTTP, HTTPS, required ports and services are enabled in the firewall.

3. Cause: WebSite could not complete a loopback request in WordPress

To run scheduled events, we use Loopback requests. Also, it is used by the built-in editors for themes and plugins to verify code stability. When the loopback request fails, it means features relying on them are not currently working as we expect. However, this happens if the loopback request is disabled.

Fix: We suggest adding the below code to the “wp-config.php” file and save it.

define(‘ALTERNATE_WP_CRON’, true);

This code will use the alternative Cron job system that can solve the problem generally.

4. Cause: Using curl with a port assignment in the URL

Fix: We suggest using a different port

5. Cause: If curl is asked to do plain HTTP on a server that does HTTPS.

Fix: In this case, we suggest to try the command using https instead of HTTP.

6. Cause: It can be due to server redirection

Fix: Here, we try executing the command using curl -L

[Need any further assistance in fixing curl errors? – We’re available 24*7]

Conclusion

In short, this error occurs when the libcurl didn’t receive any response from the server after it sent off its request. Today, we saw the resolution to this curl error.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Источник

Я периодически сталкивался с этой ошибкой и не мог понять. Гугл не помог.

Я наконец узнал. Я запускаю пару док-контейнеров, среди них NGINX и Apache. Предлагаемая команда обращается к конкретному контейнеру, запускающему Apache. Как оказалось, у меня тоже есть cron работа, выполняющая некоторые тяжелые работы, время от времени выполняемая на одном и том же контейнере. В зависимости от нагрузки это cron работа ставит на этот контейнер, он не смог своевременно ответить на мою команду, в результате error 52 empty reply from server или даже 502 Bad Gateway.

Я обнаружил и подтвердил это простым curl когда я заметил, что процесс, который я исследовал, занял менее 2 секунд, и внезапно я получил ошибку 52, затем ошибку 502, а затем снова менее 2 секунд — так что это определенно был не мой код, который не изменился. С использованием ps aux внутри контейнера я увидел другой запущенный процесс и понял.

На самом деле меня беспокоило 502 Bad Gateway от NGINX с долгими заданиями и не мог исправить это с соответствующими параметрами, поэтому я, наконец, сдался и переключил эти вещи на Apache. Вот почему меня еще больше озадачили эти ошибки.

Лекарство простое. Я только что запустил еще несколько экземпляров этого контейнера с docker service scale вот и все. docker балансирует нагрузку самостоятельно.

Что ж, это еще не все, как показал другой пример. На этот раз я выполнял однообразные задания.

Я обнаружил, что через некоторое время у меня закончилась память, используемая PHP, которую невозможно восстановить, поэтому процесс остановился.

Почему? Имея более дюжины контейнеров на машине с 8 ГБ ОЗУ, я сначала подумал, что было бы неплохо ограничить использование ОЗУ на контейнерах PHP до 50 МБ.

Тупой! Я забыл об этом, но swarmpit намекнул. Я звоню ini_set("memory_limit",-1); в конструкторе моего класса, но это доходило только до тех 50 МБ.

Поэтому я удалил эти ограничения из моего файла создания. Теперь эти контейнеры могут использовать до 8 ГБ. Этот процесс работает с Apache уже несколько часов, и похоже, что проблема решена, использование памяти превышает 100 МБ.

Еще одно предостережение: чтобы легко получать и читать отладочные сообщения, я начал указанный процесс в Opera под Windows. Это нормально, скоро появятся ошибки.

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

Источник

Привет,

Эта проблема решена или вам все еще требуется помощь?

То же самое.
Есть ли обновления по этому поводу?

screen shot 2018-01-14 at 23 06 53

У меня такая же ошибка с вызовами API (в Laravel), используя версию 6.3.3

$response = $this->client->request('PUT', route('api.category.update', ['category' => $category]), [
            'form_params' => $request->all()
        ])->getBody();

Это происходит случайно.

Полный стек:

[2018-05-30 17:52:55] staging.ERROR: cURL error 52: Empty reply from server (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)
[stacktrace]
#0 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(150): GuzzleHttp\Handler\CurlFactory::createRejection(Object(GuzzleHttp\Handler\EasyHandle), Array)
#1 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(103): GuzzleHttp\Handler\CurlFactory::finishError(Object(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory))
#2 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php(43): GuzzleHttp\Handler\CurlFactory::finish(Object(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory))
#3 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php(28): GuzzleHttp\Handler\CurlHandler->__invoke(Object(GuzzleHttp\Psr7\Request), Array)
#4 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php(51): GuzzleHttp\Handler\Proxy::GuzzleHttp\Handler\{closure}(Object(GuzzleHttp\Psr7\Request), Array)
#5 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php(66): GuzzleHttp\Handler\Proxy::GuzzleHttp\Handler\{closure}(Object(GuzzleHttp\Psr7\Request), Array)
#6 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/Middleware.php(30): GuzzleHttp\PrepareBodyMiddleware->__invoke(Object(GuzzleHttp\Psr7\Request), Array)
#7 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/RedirectMiddleware.php(70): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Request), Array)
#8 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/Middleware.php(57): GuzzleHttp\RedirectMiddleware->__invoke(Object(GuzzleHttp\Psr7\Request), Array)
#9 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/HandlerStack.php(67): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Request), Array)
#10 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/Client.php(277): GuzzleHttp\HandlerStack->__invoke(Object(GuzzleHttp\Psr7\Request), Array)
#11 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/Client.php(125): GuzzleHttp\Client->transfer(Object(GuzzleHttp\Psr7\Request), Array)
#12 /var/www/html/bakkerij/vendor/guzzlehttp/guzzle/src/Client.php(131): GuzzleHttp\Client->requestAsync('PUT', Object(GuzzleHttp\Psr7\Uri), Array)
#13 /var/www/html/bakkerij/app/Http/Controllers/CMS/CategoryController.php(84): GuzzleHttp\Client->request('PUT', 'http://dev.bakk...', Array)
#14 [internal function]: App\Http\Controllers\CMS\CategoryController->update(Object(Illuminate\Http\Request), Object(App\Models\Category))
#15 /var/www/html/bakkerij/vendor/laravel/framework/src/Illuminate/Routing/Controller.php(54): call_user_func_array(Array, Array)
#16 /var/www/html/bakkerij/vendor/laravel/framework/src/Illuminate/Routing/ControllerDispatcher.php(45): Illuminate\Routing\Controller->callAction('update', Array)
#17 /var/www/html/bakkerij/vendor/laravel/framework/src/Illuminate/Routing/Route.php(212): Illuminate\Routing\ControllerDispatcher->dispatch(Object(Illuminate\Routing\Route), Object(App\Http\Controllers\CMS\CategoryController), 'update')
#18 /var/www/html/bakkerij/vendor/laravel/framework/src/Illuminate/Routing/Route.php(169): Illuminate\Routing\Route->runController()
#19 /var/www/html/bakkerij/vendor/laravel/framework/src/Illuminate/Routing/Router.php(659): Illuminate\Routing\Route->run()
....

РЕДАКТИРОВАТЬ: исправлено

@ Kerren-Entrostat, это произошло только с моими запросами PUT, и тогда я понял, что это не проблема жрать.

У меня был бесконечный цикл в моем модельном обозревателе, который, конечно, занимал много времени, и он возвращал это исключение жрать, потому что нет ответа

У меня такая же ошибка при отправке файла размером более 1 МБ. Используется версия 6.3.2.
Мой код:

$client = new GuzzleHttpClient();
$options = [
    'multipart' => [
        [
            'name'     => 'files[]',
            'contents' => fopen('/path/to/file/larger/1MB.ext', 'r'), // or many files, the size of which together exceeds 1MB
        ],
    ]
];
$response = $client->request('POST', 'http://url.local', $options);

Полный стек:

[GuzzleHttpExceptionConnectException] 
cURL error 52: Empty reply from server (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) (0)
/var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:185
#0: GuzzleHttpHandlerCurlFactory::createRejection(object, array)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:149
#1: GuzzleHttpHandlerCurlFactory::finishError(object, object, object)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:102
#2: GuzzleHttpHandlerCurlFactory::finish(object, object, object)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php:43
#3: GuzzleHttpHandlerCurlHandler->__invoke(object, array)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php:28
#4: GuzzleHttpHandlerProxy::GuzzleHttpHandler{closure}(object, array)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php:51
#5: GuzzleHttpHandlerProxy::GuzzleHttpHandler{closure}(object, array)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php:66
#6: GuzzleHttpPrepareBodyMiddleware->__invoke(object, array)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Middleware.php:30
#7: GuzzleHttpMiddleware::GuzzleHttp{closure}(object, array)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/RedirectMiddleware.php:70
#8: GuzzleHttpRedirectMiddleware->__invoke(object, array)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Middleware.php:60
#9: GuzzleHttpMiddleware::GuzzleHttp{closure}(object, array)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/HandlerStack.php:67
#10: GuzzleHttpHandlerStack->__invoke(object, array)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Client.php:277
#11: GuzzleHttpClient->transfer(object, array)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Client.php:125
#12: GuzzleHttpClient->requestAsync(string, string, array)
    /var/www/bitrix/local/vendor/guzzlehttp/guzzle/src/Client.php:131
#13: GuzzleHttpClient->request(string, string, array)
    /var/www/bitrix/test.php:40

Причина этой строки 253 класса GuzzleHttp Handler CurlFactory, метод CurlFactory :: applyBody () https://github.com/guzzle/guzzle/blob/6.3.2/src/Handler/CurlFactory.php#L253

Временно решил проблему добавлением заголовка Content- Length: 1 по запросу:

$client = new GuzzleHttpClient();
$options = [
    // this header value is deceives this condition https://github.com/guzzle/guzzle/blob/6.3.2/src/Handler/CurlFactory.php#L253
    'headers' => [
        'Content-Length' => 1
    ],
    'multipart' => [
        [
            'name'     => 'files[]',
            'contents' => fopen('/path/to/file/larger/1MB.ext', 'r'), // or many files, the size of which together exceeds 1MB
        ],
    ]
];
$response = $client->request('POST', 'http://url.local', $options);

Но я не думаю, что это правильно. Кто-нибудь знает, почему происходит такое поведение?

PS Голый локон хорошо работает:

$pathToBigFile = '/path/to/file/larger/1MB.ext';

$postdata = array(
    'file' => new CURLFile($pathToBigFile, null, basename($pathToBigFile)),
);

if( $curl = curl_init() ) {
    curl_setopt($curl, CURLOPT_URL, 'http://url.local');
    curl_setopt($curl, CURLOPT_RETURNTRANSFER,true);
    curl_setopt($curl, CURLOPT_POST, true);
    curl_setopt($curl, CURLOPT_POSTFIELDS, $postdata);
    curl_setopt($curl,CURLOPT_ENCODING, '');
    $out = curl_exec($curl);
    curl_close($curl);
}

Кто-нибудь когда-нибудь находил для этого решение? У меня происходит то же самое.

У меня такая же ошибка, но она не может быть связана с размером файла. Я подозреваю, что из-за того, что я отправляю 4 запроса прямо при загрузке страницы на свой прокси, где я жадно пересылаю свой запрос, он как-то вылетает … Может быть?

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время не было активности. Он будет закрыт через 2 недели, если больше не будет активности. Спасибо за ваш вклад.

Здравствуйте, у меня такая же проблема. Кто-нибудь узнает, что вызвало эту проблему? Это жрет, или противоположная сторона не отвечает правильно при отправке большого файла ??
Общение выглядит так:

Host: x.x.x.x
User-Agent: GuzzleHttp/6.3.3 curl/7.64.0 PHP/7.4.10
Content-Type: multipart/form-data; boundary=69d74e069af293c0ea24db3508d7a725743dc1e6
Accept: application/json
Expect:
x-auth-token: ae18007986b4b1246ed4e3afc9fffcc66ad5f7ba
Content-Length: 31895351

* We are completely uploaded and fine
* Empty reply from server
* Connection #20 to host x.x.x.x left intact

При попытке отправить его через curl он работает правильно.

Источник

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Guvcview error no video device found
  • Gutrend style 220 ошибки
  • Gutrend style 200 aqua ошибки
  • Gutrend fun 110 pet ошибка e10
  • Guru meditation virtualbox как исправить

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии