https://pecl.php.net/ serves responses gzip-compressed unconditionally

[cschug]

Description

Unsure if that's the correct issue tracker for website issues with https://pecl.php.net/ but https://bugs.php.net/report.php?package=Website%20problem states it no longer accepts issues.

Anyway, since today apparently https://pecl.php.net/ serves responses gzip-compressed unconditionally, even if requesting no compression.

To reproduce:

$ curl -s --no-compressed https://pecl.php.net/ | file --mime-type -
/dev/stdin: application/gzip

Expected result:

$ curl -s --no-compressed https://pecl.php.net/ | file --mime-type -
/dev/stdin: text/html

I'm pretty sure it was working at least until yesterday, 2025-06-30.

PHP Version

not relevant, https://pecl.php.net/ website issue.

Operating System

not relevant, https://pecl.php.net/ website issue.

[Girgias]

@derickr this seems related to the recent migration of PECL to the new box and possible the fix for the channel update fix?

[derickr]

@cschug How is this causing an issue?

[cschug]

@derickr User agents which aren't capable to deal with gzip-compressed content cannot process the content. As of today, https://pecl.php.net/ always responds with gzip-compressed content, regardless which Accept-Encoding request header values which aren't gzip the user agents sets. As far a I can see this is a violation of RFC9110, section 12.5.3.

I was made aware of this issue because I'm running a (admittedly very dated) Perl script checking once per day for new versions of PECL modules I use. Therefore I don't have any higher precision when the problem started.

[derickr]

I know when and why it happened. I moved the pecl.php.net machine to behind a CDN today, and onto a new server.

The "pecl install" tool also suffers from a similar issue (among others), and we deliberately turn off gzip compression for that: https://github.com/derickr/php-infrastructure/blob/main/roles/properties/pecl/templates/pecl.php.net.conf#L70 — but only for /channel.xml and everything under /rest. (This disabling for /channel.xml doesn't seem to work either when it is cached, so we don't right now).

You should be able to make this work by requesting (say) https://pecl.php.net/rest/r/xdebug/allreleases.xml and that will not be gzip compressed:

$ curl --no-compressed https://pecl.php.net/rest/r/xdebug/allreleases.xml  | file --mime-type -
/dev/stdin: text/xml

For some reason, the CDN always requests gzip content from our origin, and then ignores what the client asked for. I can ask them to have another look at this too. It is something I would like to get sorted, but I am currently not sure whether we can easily accommodate this.

[cschug]

Ah, I see, thanks for the explanation. Does the origin server set a Vary: Accept-Encoding response header so the CDN can be made aware that responses might differ dependent on the value of Accept-Encoding?

Thanks for the hint regarding those XML files, they should do the trick!