{{ message }}
Repository navigation
Use HTTP/2 instead of 1.1 #587
Description
Feature Request
Is your feature request related to a problem? Please describe.
Currently requests are done with HTTP 1.1:
>>> client.servers.get_all()
2025-11-11 13:25:32,402 - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): api.hetzner.cloud:443
2025-11-11 13:25:32,630 - urllib3.connectionpool - DEBUG - https://api.hetzner.cloud:443 "GET /v1/servers?page=1&per_page=50 HTTP/1.1" 200 178
Describe the solution you'd like
The requests should use HTTP 2 for better performance as the servers do support it
$ curl -i https://api.hetzner.cloud
HTTP/2 404
Describe alternatives you've considered
Staying with HTTP 1.1 and accepting worse performance.
Teachability, Documentation, Adoption, Migration Strategy
urllib3 underpinning requests does not support HTTP 2 so this requests switching the library.
https://github.com/urllib3/urllib3/milestone/10
Here httpx is suggested as an alternative. Would it be acceptable?
https://webscraping.ai/faq/urllib3/can-i-use-urllib3-with-http-2-protocol
Activity
[-]Use HTTP 2 instead of 1.1[/-][+]Use HTTP/2 instead of 1.1[/+]jooola commentedon Nov 11, 2025
Is that an actual problem for your usage of the SDK?
betelgeuse commentedon Nov 11, 2025
My experience with https://github.com/ansible-collections/hetzner.hcloud has been rather slow performance so I started thinking about improvements to the stack. However, I haven't done proper research whether HTTP/2 would make a difference. It would make sense though that things like multiplexing pagination would be useful.
koval01 commentedon May 23, 2026
I don't think switching to HTTP/2 makes sense for this library.
Switching from requests to httpx (the only real way to get full HTTP/2 support) would require significant code rework, the introduction of global session management, and would complicate cleanup, threading, and asynchronous usage, as well as increase the maintenance burden. For typical hcloud-python usage—primarily sequential calls, server creation, and polling for actions—the real benefits of multiplexing and header compression would be negligible.
The complexity and likelihood of introducing new issues significantly outweigh any potential performance gains. I would suggest closing this issue as “will not be fixed” or “very low priority.”
If we really want to go down this road, we could also switch to curl_cffi for HTTP/3, but at that point we're just doing tech fashion, not solving real problems.