perf(client): enable HTTP/2 and brotli support in internal HTTP client #55433
Conversation
ernolf
requested review from
ArtificialOwl,
SystemKeeper,
blizzz,
leftybournes,
nfebe,
nickvergessen and
szaimen
and removed request for
a team
- Prefer HTTP/2 by setting RequestOptions::VERSION => "2.0" so clients
that respect PSR-7 request version will prefer HTTP/2.
- Add a curl hint (CURLOPT_HTTP_VERSION) to prefer HTTP/2 via ALPN
(CURL_HTTP_VERSION_2TLS or CURL_HTTP_VERSION_2_0 fallback) while allowing
automatic fallback to HTTP/1.1.
- Advertise Brotli ("br") in Accept-Encoding when the php-brotli extension
is available (detected via function_exists('brotli_uncompress')), otherwise
fall back to gzip.
Notes:
- The PSR-7 request version is used as a hint for HTTP client libraries;
setting the version to "2.0" signals a preference for HTTP/2 at the request
abstraction level.
- The curl option is defensive: it prefers HTTP/2 where libcurl supports it
(via ALPN), but will not break on older libcurl/builds (uses defined()).
Compatibility:
- Fully backwards compatible: if the php-brotli extension is not present,
no Brotli usage will occur and behaviour remains equivalent to previous
(gzip).
Signed-off-by: ernolf <raphael.gradenwitz@googlemail.com>
ernolf
force-pushed
the
ernolf/enh/http2-brotli-client
branch
from
4b4ab4d to
11785c9
Compare
Signed-off-by: ernolf <raphael.gradenwitz@googlemail.com>
ernolf
force-pushed
the
ernolf/enh/http2-brotli-client
branch
from
11785c9 to
65aa731
Compare
This comment was marked as spam.
This comment was marked as spam.
|
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.) |
|
Hey @ernolf, are you ok with adding the changes that Carl and I suggested? If you don't have the time or energy, let us know and one of us can take over and finish the PR :) Cheers! |
Signed-off-by: ernolf <raphael.gradenwitz@googlemail.com>
✅ - Done! |
|
Can you fix the conflict please? |
Signed-off-by: Raphael Gradenwitz <39901936+ernolf@users.noreply.github.com>
Signed-off-by: ernolf <raphael.gradenwitz@googlemail.com>
✅ Conflicts resolved and pushed. I was not able to fix the failing This appears to be unrelated to the changes in this PR (the remaining Cypress failure is about app loading, not HTTP client behavior). |
Summary
This patch updates the internal Nextcloud HTTP client to prefer HTTP/2 where available and to advertise Brotli ("br") in the Accept-Encoding header when the native php-brotli extension is present. The change is designed to be fully backwards compatible: if Brotli support isn't available in the runtime, the client behaves as before (gzip) and cURL will fall back to HTTP/1.1 if HTTP/2 is not supported by the server or the libcurl build.
Motivation
What changed:
RequestOptions::VERSION => '2.0'to indicate a preference for HTTP/2 at the PSR-7 request level.CURLOPT_HTTP_VERSIONis set to prefer HTTP/2 viaCURL_HTTP_VERSION_2TLS(orCURL_HTTP_VERSION_2_0as fallback) when those constants are available. This leverages ALPN for protocol negotiation and gracefully falls back to HTTP/1.1 when necessary.brwhen the php-brotli extension is available (detected viafunction_exists('brotli_uncompress')), otherwise we keepgzip.Backwards compatibility:
gziponly. If libcurl or the remote server does not support HTTP/2, the connection falls back to HTTP/1.1 automatically.TODO
Checklist
3. to review, feature component)stable32)