[Bug] Can't connect to marketplace anymore when curl uses brotli compression

[pixelbrackets]

What happened?

I moved a matomo instance, according to the official guide https://matomo.org/faq/how-to-install/faq_18/ from "example.com/depot/piwik/" to "trace.example.com".

I cant reach the marketplace anymore. It keeps showing

There was an error reading the response from the Marketplace: Please try again later.

I debugged Matomo to find the requested URI:

https://plugins.matomo.org/api/2.0/plugins?keywords=&purchase_type=&query=&sort=lastupdated&release_channel=latest_stable&prefer_stable=1&piwik=5.0.3&php=8.1.28&mysql=10.6.17-MariaDB&num_users=9&num_websites=14

The response for this URI is always empty.

System report and security report in the Matomo backend look good and dont mentian any missing or faulty software.

Calling the URI from CLI works fine as well (curl https://plugins.matomo.org/… gives the expected JSON reponse).

Any hints what could be wrong here?

What should happen?

Marketplace is accessible

How can this be reproduced?

Try to open the marketplace page. Try to run "Looking for updates" in plugin page.

Matomo version

5.0.3

PHP version

8.1

Server operating system

No response

What browsers are you seeing the problem on?

No response

Computer operating system

Linux

Relevant log output

No response

Validations

• Read our Contributing Guidelines.
• Follow our Security Policy.
• Check that there isn't already an issue that reports the same bug to avoid creating duplicates.
• The provided steps to reproduce is a minimal reproducible of the Bug.

[pixelbrackets]

Calling the URI from CLI works fine as well (curl https://plugins.matomo.org/… gives the expected JSON reponse).

When calling the URI from a simple PHP testscript using Guzzle I also get a response from the Matomo endpoint.

When I pass a random URL to the method trying to fetch the data (Piwik\Plugins\Marketplace\Api\Service::fetch()) then it will return a response as well.

When I mirror the JSON reponse of the marketplace from another instance, then the request is fine as well.

So curl is working ✔️, the server is able to handle requests (seems to be no firewall issue) ✔️ . Somehow the connection from Matomo to the Matomo marketplace URI is faulty.

[pixelbrackets]

The connection error lead me into Matomos HTTP class, which sets up custom curl request commands.

In there I found the error. The following line instructs curl to always request all encodings it supports:

matomo/core/Http.php

Lines 677 to 680 in 4a5a877

	// see https://github.com/matomo-org/matomo/pull/17009 for more info
	// NOTE: we only do this when CURLOPT_RANGE is not being used, because when using both the
	// response is empty.
	$curl_options[CURLOPT_ENCODING] = "";

(introduced in #17009 and afaik reasonable).

Outgoing requests show that my server sends the header accept-encoding: deflate, gzip, br. When I remove brotli (br), then Matomo will work just fine and the marketplace is available again. When I use brotli only, the response is empty.

I was able to reproduce the issue with a simple script:

<?php

$requestUrl = 'https://plugins.matomo.org/api/2.0/plugins?keywords=&purchase_type=&query=&sort=lastupdated&release_channel=latest_stable&prefer_stable=1&piwik=5.0.3&php=8.1.28&mysql=10.6.17-MariaDB&num_users=9&num_websites=14';
//$requestUrl = 'https://httpbin.dev/brotli';

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $requestUrl);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_ENCODING, 'br');
$data = curl_exec($ch);
print_r($data);

However: This script works fine on a local test machine.

Running the request via CLI works on both machines (curl --output -H 'Accept-encoding: br' "https://plugins.matomo.org/api/2.0/plugins?keywords=&purchase_type=&query=&sort=lastupdated&release_channel=latest_stable&prefer_stable=1&piwik=5.0.3&php=8.1.28&mysql=10.6.17-MariaDB&num_users=9&num_websites=14"), so this seems to be a php-curl issue.

I have contacted my hosting provider, maybe php-curl was not compiled with brotli.

FYI: I wrote the a Guzzle script for the same request and this works. Guzzle decompresses the reponse using a stream wrapper.

[pixelbrackets]

I have contacted my hosting provider, maybe php-curl was not compiled with brotli.

The hosting uses Red Hat Enterprise Linux 7 with curl version 7.29. Since this is a long-term support OS, that's a rather old version, and the provider therefore installed an additional curl. PHP is provided in multiple versions with the popular Remi repo (https://rpms.remirepo.net/). Since these versions are supposed to run on RHEL 7, they are built against version 7.29. Brotli is supported in curl since version 7.57 (https://curl.se/changes.html).

Due to the mentioned empty CURLOPT_ENCODING argument php-curl now sends the “newer” list of accepted values, which includes brotli, but is not able to work with the response eventually.

My hotfix: I hardcoded $curl_options[CURLOPT_ENCODING] = 'deflate, gzip' in line

matomo/core/Http.php

Line 680 in 4a5a877

$curl_options[CURLOPT_ENCODING] = "";

Question: This issues did not pop up until this month. My provider said that they run this software setup for a long time already. Did the Matomo Marketplace API Server maybe activate brotli responses just now?

Suggestion: As written before, if Matomo would work with a stream wrapper - as Guzzle does - this would not trigger an error. Maybe add a stream wrapper or even replace the custom curl scripts with a library like Guzzle? Depends how many users are affected by the issue.

[martinheise]

I can reproduce the exact same behaviour, including @pixelbrackets test script and the fix.
System is: Red Hat Enterprise Linux Server release 7.9
Curl version is 8.7.1, though

[sgiehl]

@patrickli @samjf Were there any changes done to our Marketplace API Server recently, which might cause the problem?

[patrickli]

Not anything I'm aware of. @samjf did we upgrade PHP version for it? I just checked and it is default.