fix(http-client): detect brotli support via libcurl, not PHP extension#60262
Conversation
- Fixes a regression introduced in #55433. Signed-off-by: ernolf <raphael.gradenwitz@googlemail.com>
|
/backport to stable33 |
…BROTLI Signed-off-by: ernolf <raphael.gradenwitz@googlemail.com>
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
Summary
function_exists('brotli_uncompress')checks the wrong layer.In Guzzle's curl handler,
CURLOPT_ENCODINGis set to''which instructs libcurl to decompress all encodings it was compiled with. All decompression happens inside libcurl. The PHPbrotli_uncompress()function is never called in this pipeline.The wrong check creates two silent failure modes:
Content-Encoding: br, libcurl passes compressed bytes through, application receives garbled dataAccept-Encodingdespite full supportThe correct signal is
CURL_VERSION_BROTLIincurl_version()['features'], which reflects whether this libcurl binary was compiled withlibbrotlidec.This is also how the Nextcloud News app (
FetcherConfig.php) detects brotli support.Checklist
3. to review, feature component)stable32)AI (if applicable)