Hello - after the December 2019 updates, we are receiving the following error. Our client code calls into Guzzle at #2, so we don't call GuzzleHttp_idn_uri_convert() directly:

[28-Dec-2019 17:57:20 UTC] PHP Fatal error: Uncaught Error: Call to undefined function GuzzleHttp_idn_uri_convert() in wp-content/plugins/q4vrplugin/vendor/guzzlehttp/guzzle/src/Client.php:220 Stack trace: #0 guzzlehttp/guzzle/src/Client.php(155): GuzzleHttp\Client->buildUri(Object(GuzzleHttp\Psr7\Uri), Array)

#1 guzzlehttp/guzzle/src/Client.php(183): GuzzleHttp\Client->requestAsync('GET', 'units', Array)

#2 plugin/Models/ApiClient.php(97): GuzzleHttp\Client->request('GET', 'units', Array)

Please let me know what additional information I can provide to assist.

Thanks!

Jim

I expected that using $client->getAsync() with Curl will fire request immediately, leaving me some time to perform additional work before it completes:

$req = $client->getAsync('http://api.com/get_a_lot_of_data'); // Shouldn't request be sent here ? ...

// do something while the long request is in progress in order not to waste time
do_work();

$req->then(...);
$req->wait(); // ... so here request can already complete

But it turns out, that request will actually be fired only when you call $req->wait(), acting like a plain synchronous request.

This fixes #312 and allows for traversal of XML documents including nested attributes and namespaces.

• [x] Remove implicit conversion of SimpleXMLElement to array
• [x] Add traversal of XML document in XMLVisitor.
• [x] Investigate ways of working around OperationResponseParser::visitAdditionalProperties() limitations
• [x] Add XML namespace support traversal.
• [x] Add combination tests for OperationResponseParser
• [x] Add complex nested XML structures' tests with attributes and various additionalProperties stances.
• [x] Protect xml and json structures in Visitors
• [x] Optimize XmlVisitor::xmlToArray()
• [x] Incorporate support for top-level arrays and model location definition.
• [x] Fix Response\HeaderVisitor with additionalProperties

Guzzle version(s) affected: 6.5.3 PHP version: 7.3.16 (hint: php --version) cURL version: 7.69.1 (hint: php -i | grep cURL)

Description
My Telegram Bot is giving me this error when upgrade from 6.4.0 to 6.5.3:

idn_to_ascii(): INTL_IDNA_VARIANT_2003 is deprecated

in Utils.php line 35 at HandleExceptions->handleError(8192, 'idn_to_ascii(): INTL_IDNA_VARIANT_2003 is deprecated', '/home/erich33/vendor/guzzlehttp/guzzle/src/Utils.php', 35, array('uri' => object(Uri), 'options' => 0, 'idnaVariant' => 0))

How to reproduce
When somebody message to my Telegram Bot, I have a script which send to my email the Exceptions, and turns now a hell with this error.

Possible Solution
Downgrade to 6.4? Something with symfony idn?

Additional context
My actual composer.lock:

{ "name": "laravel/laravel", "type": "project", "description": "The Laravel Framework.", "keywords": [ "framework", "laravel" ], "license": "MIT", "require": { "php": "^7.3", "artesaos/seotools": "^0.17.1", "binarytorch/larecipe": "^2.2", "biscolab/laravel-recaptcha": "^4.0", "facebook/graph-sdk": "^5.7", "fideloper/proxy": "^4.0", "guzzlehttp/guzzle": "^6.5", "intervention/image": "^2.5", "irazasyed/telegram-bot-sdk": "3.1.0", "laravel-notification-channels/facebook": "^0.1.0", "laravel-notification-channels/facebook-poster": "^2.0", "laravel-notification-channels/telegram": "^0.3.0", "laravel-notification-channels/twitter": "^3.0", "laravel/framework": "^6.2", "laravel/passport": "^8.4", "laravel/socialite": "^4.1", "laravel/tinker": "^2.2", "overtrue/laravel-like": "^2.0", "predis/predis": "^1.1", "renatomarinho/laravel-page-speed": "^1.8", "rennokki/befriended": "^3.0", "rennokki/rating": "^2.0", "spatie/laravel-permission": "^3.11", "spatie/laravel-responsecache": "^6.3", "spatie/laravel-sitemap": "^5.3", "spatie/schema-org": "^2.2", "tedivm/fetch": "^0.7.1" }, "require-dev": { "barryvdh/laravel-debugbar": "^3.2", "beyondcode/laravel-dump-server": "^1.0", "filp/whoops": "^2.0", "fzaninotto/faker": "^1.4", "mockery/mockery": "^1.0", "nunomaduro/collision": "^3.0", "phpunit/phpunit": "^9.0" }, "config": { "optimize-autoloader": true, "preferred-install": "dist", "sort-packages": true }, "extra": { "laravel": { "dont-discover": [] } }, "autoload": { "files": [ "app/Helpers/Helper.php" ], "psr-4": { "App\": "app/" }, "classmap": [ "database/seeds", "database/factories" ] }, "autoload-dev": { "psr-4": { "Tests\": "tests/" } }, "minimum-stability": "dev", "prefer-stable": true, "scripts": { "post-autoload-dump": [ "Illuminate\Foundation\ComposerScripts::postAutoloadDump", "@php artisan package:discover --ansi", "@php artisan optimize", "@php artisan view:clear", "@php artisan cache:clear", "@php artisan responsecache:clear" ], "post-root-package-install": [ "@php -r "file_exists('.env') || copy('.env.example', '.env');"" ], "post-create-project-cmd": [ "@php artisan key:generate --ansi" ] } }

I need to download a lot of remote packages. I am using the Pool function according to the documentation here: http://docs.guzzlephp.org/en/latest/quickstart.html#making-a-request

I'm not sure how I can free up the used memory. The packages are all small but several tens of thousands. How can I properly unset/free $response? unset(), $response->getBody()->close(); all seem not to do what I want.

use GuzzleHttp\Pool;
use GuzzleHttp\Client;
use GuzzleHttp\Psr7\Request;

require __DIR__ . '/vendor/autoload.php';

$client = new Client(['base_uri' => '...']);

$requests = function ()
{
    ...

    yield $index => new Request('GET', ...);
};

$pool = new Pool($client, $requests(), [
    'concurrency' => 50,
    'fulfilled' => function ($response, $index)
    {
        $content = $response->getBody()
                            ->getContents();

        file_put_contents('storage/' . $index, $content);

        print 'fulfilled index:' . $index . PHP_EOL;
    },
    'rejected' => function ($reason, $index)
    {
        print 'rejected index:' . $index . PHP_EOL;
    },
]);

$promise = $pool->promise();

$promise->wait();

Guzzle: 6.2.3 PHP: 7.3.16 Curl: 7.19.7

Description

Library used for Google Shopping API product feeds

Feeds worked successfully every 20 minutes for 2 years and first 5 hours of 17 April 2020

Then:

PHP Fatal error: Uncaught GuzzleHttp\Exception\RequestException: cURL error 2: easy handle already used in multi handle (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:162 Stack trace: #0 ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(129): GuzzleHttp\Handler\CurlFactory::createRejection(Object(GuzzleHttp\Handler\EasyHandle), Array) #1 ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(89): GuzzleHttp\Handler\CurlFactory::finishError(Object(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory)) #2 ../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 ../vendor/guzzlehttp/guzzle/src/Handl in ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php on line 162

No change to server, site configuration or any associated php or library files.

Same error every time the script now runs.

I am not a programmer but can follow instructions!

Any leads or guidance will be appreciated as the feed developer is no longer available.

TIA

Hi everyone,

I know this has been extensively discussed here https://github.com/guzzle/guzzle/issues/1722 but unfortunately the exception truncation is a constant pain-point for me to the point that I'm almost maintaining a fork of Guzzle just to change that number. I understand a few of the points made in the thread such as the uncertainty of the size of the content in the response. A counter-argument that I would like to raise is the fact that we are forced into treating Guzzle Exceptions differently in our systems because Guzzle won't let me see enough of the response content. And then I have to turn this

$client->get($resource);

into this

try {
    $client->get($resource);
} catch(BadResponseException $e) {
    $e->getResponse()->getBody()->getContents();
}

throughout my entire platform. Sometimes we include packages that make usage of Guzzle and the package won't let me see the full error message as well.

This seem such a small issue that brings a lot of headache. an extremely simple static Client::MESSAGE_SIZE = 6400; would suffice for me and probably for most of the people suffering from this. The pain-point for me is located on 5xx requests and 4xx requests between internal microservices. Those are not production-ready code that I'm working on and trying to stabilize them in a way that I'll never have a 5xx or 4xx, but I don't know what to fix because I can't see the error message.

Something else described on the linked thread was this:

Obviously you don't want to log that 10k JSON, so in this case you should extract the necessary/useful information from the body, and properly log it instead of the exception message.

Why Obviously I don't want to log that 10k JSON? What if I do? Even if I don't need the 10k, 120 characters is still not enough for me to see which table name does not exist from a standard MySQL error.

Anyway, I would really hope that this could be revisited. I would like to finish by saying that what Guzzle is doing right now is forcing me to catch an exception not because I should catch it, but because I cannot see the exception's message if I don't. I would like to be able to only catch exceptions that I really need to catch and let all other exceptions be reported.

Thanks for the this amazing tool.

I'm going to preface this by saying I'm not sure if it is a bug, or simply something that needs to be documented. Or perhaps I'm just using Guzzle incorrectly! :)

I was seeing extremely slow performance on sequential Guzzle requests. For example, here is a benchmark where I am issuing 100 sequential POST requests ( not in parallel, these are entirely serial) with request bodies of various sizes (from about 20 bytes up to 5kb):

    Method Name             Iterations    Average Time      Ops/second
    ---------------------  ------------  --------------    -------------
    curlMultiHandleSmall : [100       ] [0.0012452316284] [803.06344]
    curlMultiHandleMedium: [100       ] [0.0025620341301] [390.31486]
    curlMultiHandleLarge : [100       ] [0.0020819020271] [480.33000]
    guzzleSmall          : [100       ] [0.0424066281319] [23.58122]
    guzzleMedium         : [100       ] [0.0430183744431] [23.24588]
    guzzleLarge          : [100       ] [0.0423791432381] [23.59651]

curlMultiHandle is my own simple, naive implementation of a curl multi-handle transport layer. I wrote it initially just as a placeholder so I could implement everything else. I'm now replacing it with Guzzle for obvious reasons (unit test coverage, battle-hardened with bug fixes, etc).

However, the performance drop was staggering. A peek at xdebug/cachegrind shows that Guzzle is eating time with curl_multi_select (times are absolute and in milliseconds):

What is surprising is that this behavior is not found in my naive implementation, despite the fact that the actual multi-handle code is extremely similar (pretty much identical process, just simplified). Representative cachegrind from my code shows that curl_multi_select isn't even represented (most of the time is actually taken by curl_multi_exec, but its an order of magnitude less than Guzzle):

So that's odd. I spent a few hours debugging and eventually thought to look at curl's transfer stats. Turns out, Guzzle's "speed_download" and "speed_upload" are atrociously slow:

            [total_time] => 0.040236
            [namelookup_time] => 2.7E-5
            [connect_time] => 2.7E-5
            [pretransfer_time] => 9.2E-5
            [size_upload] => 19
            [size_download] => 100
            [speed_download] => 2485
            [speed_upload] => 472

Compared to my implementation:

            [total_time] => 0.001016
            [namelookup_time] => 1.5E-5
            [connect_time] => 1.5E-5
            [pretransfer_time] => 7.6E-5
            [size_upload] => 19
            [size_download] => 100
            [speed_download] => 98425
            [speed_upload] => 18700

So with that in mind, I continued digging through Guzzle and discovered that Guzzle loads all request bodies into a PHP temp memory stream. After a bit more digging, I discovered the body_as_string parameter to force Guzzle to pass the request body as a string.

$options = array(
    'curl.options' => array(
        'body_as_string'   => true,
    )
);
$client = new \Guzzle\Http\Client(null, $options);

Turns out that was the issue. Benchmark:

    Method Name             Iterations    Average Time      Ops/second
    ---------------------  ------------  --------------    -------------
    curlMultiHandleSmall : [100       ] [0.0027452158928] [364.27008]
    curlMultiHandleMedium: [100       ] [0.0023763251305] [420.81784]
    curlMultiHandleLarge : [100       ] [0.0021409964561] [467.07224]
    guzzleSmall          : [100       ] [0.0032468485832] [307.99096]
    guzzleMedium         : [100       ] [0.0037671685219] [265.45136]
    guzzleLarge          : [100       ] [0.0039931154251] [250.43103]

curl stats show normal upload/downloat speed:

    [total_time] => 0.000739
    [namelookup_time] => 8.0E-6
    [connect_time] => 8.0E-6
    [pretransfer_time] => 2.7E-5
    [size_upload] => 19
    [size_download] => 100
    [speed_download] => 135317
    [speed_upload] => 25710

And finally the cachegrind looks much improved:

So I guess that's a long winded way of saying " Hey, there is a performance issue but I'm not sure why ". I don't use php://temp streams much myself, so I'm not sure what issues are associated with them. I wouldn't assume they are slow, since they are memory streams, but clearly something is going wrong.

I would love to hear your thoughts!

I'm 100% positive I have curl installed - I use it often, and have for many hears. That said, when I run composer from the Tumblr PHP API (which has guzzle as a dependency), it fails with:

Loading composer repositories with package information
Installing dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - guzzle/guzzle v3.8.1 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.8.0 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.7.4 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.7.3 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.7.2 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.7.1 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.7.0 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.6.0 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.5.0 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.4.3 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.4.2 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.4.1 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.4.0 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.3.1 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.3.0 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.2.0 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.1.2 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.1.1 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - guzzle/guzzle v3.1.0 requires ext-curl * -> the requested PHP extension curl is missing from your system.
    - Installation request for guzzle/guzzle >=3.1.0,<4 -> satisfiable by guzzle/guzzle[v3.1.0, v3.1.1, v3.1.2, v3.2.0, v3.3.0, v3.3.1, v3.4.0, v3.4.1, v3.4.2, v3.4.3, v3.5.0, v3.6.0, v3.7.0, v3.7.1, v3.7.2, v3.7.3, v3.7.4, v3.8.0, v3.8.1].

WAMP, Windows 8.1

Is this a known issue, or am I missing something?

TYIA

Hello, I'm actually trying to use Auth0 integration on a Prestashop module, but after installed the integration with Composer, i've this error :

[PrestaShop] Fatal error in module file: /var/www/html/modules/prestashop/vendor/guzzlehttp/guzzle/src/Client.php:236 Unsupported operand types

Is that a bug ? It's actually stucking me. Thanks in advance.

Lucas

I'm running Yosemite beta 2, I have PHP-5.6 installed via homebrew compiled against homebrew-curl and homebrew-openssl. Guzzle can't verify SSL certs. For example:

$client = new \GuzzleHttp\Client();
$response = $client->get('https://google.com');
return $response;

results in a RequestException with error message cURL error 51: SSL: certificate verification failed (result: 5)

Guzzle version(s) affected: 7.4.1 PHP version: 8.0.7 (hint: php --version) cURL version: 7.29.0 (hint: php -i | grep cURL)

Description
When using the proxy => no request option guzzle fails to ignore the proxy if ENV vars are present on the server i.e. http_proxy or https_proxy.

This is because the no option only applies the CURLOPT_PROXY if the host is not in the list. So when ignoring it doesn't apply the curl option so falling back to the proxy that is set in the ENV var.

How to reproduce
Create http_proxy & https_proxy ENV var pointing to a proxy. Set the proxy => no request option to the host of a request. Send a request and the proxy will be used and not ignored.

Possible Solution
The following lines of code in the CurlFactory.php:444 could be changed to set the CURLOPT_PROXY to an empty string when a proxy is not required. From:

if (isset($options['proxy'][$scheme])) {
    $host = $easy->request->getUri()->getHost();
    if (!isset($options['proxy']['no']) || !Utils::isHostInNoProxy($host, $options['proxy']['no'])) {
        $conf[\CURLOPT_PROXY] = $options['proxy'][$scheme];
    }
}

To:

if (isset($options['proxy'][$scheme])) {
    $host = $easy->request->getUri()->getHost();
    if (isset($options['proxy']['no']) && Utils::isHostInNoProxy($host, $options['proxy']['no'])) {
        $conf[\CURLOPT_PROXY] = '';
    } else {
        $conf[\CURLOPT_PROXY] = $options['proxy'][$scheme];
    }
}

Additional context
Currently the no option can not be used by itself and requires the http or https settings to be applied also. Maybe consider refactoring this function to allow the no to be used even when the the other settings have not been used for cases when they have been set in the ENV vars.

Guzzle version(s) affected: 7.5.0 PHP version: not relevant cURL version: not relevant

Description
The unshift, push, before, after methods of \GuzzleHttp\HandlerStack do not provide enough detail about the callable parameter they expect. This causes Psalm to fail when providing a callable while specifying its types to HandlerStack, and forces further investigation for those using the PHPDoc as a reference.

How to reproduce
Read the PHPDoc and observe that it does not provide enough information, and also https://psalm.dev/r/3a3860028f.

Possible Solution
Specify the type:

/**
 * @param callable(callable(RequestInterface $request, array $options): PromiseInterface): callable $middleware Middleware function
 */

The following issue has been fixed: When using fromString(), for the following kind of incorrectly formed cookie fr=synced; Max-Age=604800 Expires=Mon, 12 Dec 2022 13:27:50 GMT; Domain=.emxdgt.com; Path=/; SameSite=None; Secure; HttpOnly it gives A non well formed numeric value encountered in /app/proxy/vendor/guzzlehttp/guzzle/src/Cookie/SetCookie.php notice

Description Describe &$container parameter of \GuzzleHttp\Middleware::history by psalm annotation so we do not have to do it in a test code.

Example At the moment we must describe types manually

$requests = [];
$history = Middleware::history($requests);
/** @var array<int, array{request: Request}> $requests */
$handlers->push($history);
$request = $requests[0]['request'];
$this->assertEquals('someUrl', request->getUri());

But it would be more convenient without manual annotations

WDYT?

This PR adds explicit permissions section to workflows. This is a security best practice because by default workflows run with extended set of permissions (except from on: pull_request from external forks). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an injection or compromised third party tool or action) is restricted. It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.

It'd be useful to add Client::withConfig() to allow derivating a custom-configured client from a preexisting one, eg to change the default timeout for a local need, etc.