Setting

$options['curl'][CURLOPT_ACCEPT_ENCODING] = '';

tells libcurl to advertise all encodings it was built with (e.g. br, zstd, gzip, deflate).
However Guzzle’s response decoding is done in PHP, not by libcurl.

Guzzle only transparently decodes:

• gzip
• deflate
• br only if ext-brotli (brotli_uncompress()) is available

So this configuration can cause a real protocol mismatch:

1. libcurl advertises br
2. the server selects Content-Encoding: br
3. PHP/Guzzle cannot decode it
4. the client receives still-compressed bytes and treats them as plain text

That leads to:

• corrupted responses
• JSON decode failures
• empty or garbage payloads
• subtle data corruption with no explicit error

This is not theoretical — most PHP builds ship without ext-brotli, while libcurl in modern distros often supports Brotli and Zstd.

PR #55433 solves this correctly by advertising br only when PHP can actually decode it (function_exists('brotli_uncompress')), otherwise falling back to gzip, with full test coverage.

That keeps HTTP/2 + modern compression while guaranteeing that every negotiated encoding is safely decodable by Guzzle.