You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be possible to force the httpx client to use HTTP/2 to communicate with the server without TLS?
I'm using it as
client = AsyncClient(http_versions=["HTTP/2"])
but it still (reasonably tho) uses HTTP/1.1.
Most of the clients are trying to negotiate the update to HTTP/2 over HTTP/1.1 before as well, which is desired behaviour, but it might be handy for easier development and/or debugging.
There's hyper.HTTP20Connection that enforces h2, but it gets a bit out of sync from h2 itself.
To allow for this I think we'd need to add support for the HTTP header Upgrade: h2c right?
(Rather than the current HTTPS-only connections which are ALPN-negotiated.)
I'd be okay with us supporting that - it just needs the extra work is all.
Thanks, @sethmlarson, yes that makes sense.
To be honest, I was looking for some shortcuts with setting up the client for testing for the HTTP/2 implementation against the server-side.
I'd agree with Tom that this could be supported, but it'd just need someone to work on it.
If your use case is local HTTP/2 testing, I guess the main obstacle is setting up a local self-signed TLS certificate. So in the meantime, would adding a section or some links to our docs about this help alleviate the issue?
Thanks a lot @florimondmanca, yes, it would definitely be an option. As it's not very obvious how to use self-signed certificates.
On the other hand, I gave it a bit of though, and I think there can be a valid example.
Indeed, browsers don't support unencrypted traffic, but your own APIs might not. And if we have a number of services that communicate with each other within the private network behind some firewall we can save a bit on encryption overhead. Sometimes it can be such a practice to terminate ssl at the load balancer.
Tho, not all of HTTP/2 features would make sense for APIs as for browsers, but at least multiplexing can be helpful.
Another thing, that upgrade flow can actually be handy, but it seems to worth another ticket.
I may try to help with it, but I want to finish the support for uvicorn first.
Ah, so the goal is to test the Uvicorn HTTP/2 implementation? 😄 Sounds exciting.
I think there's not a pressing need otherwise to add support for unencrypted HTTP/2, and as you wrote it's probably worth a different ticket spun up from this one.
If you all are OK with it I'll close this, and open one about documenting usage of self-signed certificates. Thanks @gvbgduh!
Reacted by Vyacheslav Vorobyov
Reacted by George Bogodukhov and shipenghao19961225
Yeah, I'm happy with it. Thanks @florimondmanca!
I guess those 2 cases (unencrypted traffic within secure net and the upgrade flow) may arise at some point eventually, but not sure it's worth attention now.
Currently, 5G Core works on HTTP2 and as services are behind firewall and load balancer, they communicate using h2c to avoid encryption overload. The goal was to test these services and few implementations are available on h2c.
I am using reverse proxy for http2/TLS -> h2c but this workaround seems unstable. Implementation suggested in #873 would be really helpful
"Second is known as "with prior knowledge". The client does not send a first HTTP/1.1 request but directly sends the request in HTTP/2 format (with frames...) assuming "with prior knowledge" that the server understands the HTTP/2 protocol. All of this without TLS."
Hi @indomirreg, I don't we have plans in the near future to support this, certainly not pre 1.0. But I think we're all in agreement this is something we could look into so I'm reopening this issue.
Reacted by Kim Christie, indomirreg and Vyacheslav Vorobyov
A note that this somewhat ties into #304 (connection upgrades), since "unencyprted HTTP/2" via h2c is an HTTP/1.1 + an h2c upgrade. So it could be that we'd eventually make WebSocket and HTTP/2+h2c use the same "upgrade API" (?).
I also have a usecase where I test microservices from https://github.com/GoogleCloudPlatform/microservices-demo one-by-one. Those microservices don't use TLS due to in-cluster safety.
I should say that curl also fails to autodetect HTTP/2 here, but it offers a flag of --http2-prior-knowledge. With the approach of "force http/2", we don't need any complex solutions.
What would you say to following proposal: have a third value for http2 flag of Client and AsyncClient, something like this:
client=httpx.AsyncClient(http2="force")
# or client=httpx.AsyncClient(http2=httpx._types.HTTP2Flags.FORCED)
And have it propagated to SyncHTTPConnection._create_connection() and its async brother.
Does it make sense to you? Any thoughts?
Highloaded microservices in a safe cluster, is also my case. HTTP/2 has a greate feature -- multiplexing! One can say "use websocket" but you can't use 'curl' with websocket. So, HTTP/2 with its 'multiplexing' + 'ability to use curl' makes it quite convenient for APIs of highloaded microservices inside safe clusters.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Activity
lovelydinosaur commentedon Nov 4, 2019
To allow for this I think we'd need to add support for the HTTP header
Upgrade: h2cright?(Rather than the current HTTPS-only connections which are ALPN-negotiated.)
I'd be okay with us supporting that - it just needs the extra work is all.
sethmlarson commentedon Nov 4, 2019
@gvbgduh What is your use-case for HTTP/2 without TLS? All browsers that implement HTTP/2 only support via ALPN.
The other issue with that configuration example above is that in order to support HTTP/2 without TLS we have to use HTTP/1.1 to get an upgrade.
gvbgduh commentedon Nov 4, 2019
Thanks, @sethmlarson, yes that makes sense.
To be honest, I was looking for some shortcuts with setting up the client for testing for the HTTP/2 implementation against the server-side.
florimondmanca commentedon Nov 6, 2019
After some research it is true that HTTP/2 does not require encryption, but "currently no browser supports HTTP/2 unencrypted", and there seems to be various reasons why that is.
I'd agree with Tom that this could be supported, but it'd just need someone to work on it.
If your use case is local HTTP/2 testing, I guess the main obstacle is setting up a local self-signed TLS certificate. So in the meantime, would adding a section or some links to our docs about this help alleviate the issue?
gvbgduh commentedon Nov 6, 2019
Thanks a lot @florimondmanca, yes, it would definitely be an option. As it's not very obvious how to use self-signed certificates.
On the other hand, I gave it a bit of though, and I think there can be a valid example.
Indeed, browsers don't support unencrypted traffic, but your own APIs might not. And if we have a number of services that communicate with each other within the private network behind some firewall we can save a bit on encryption overhead. Sometimes it can be such a practice to terminate ssl at the load balancer.
Tho, not all of HTTP/2 features would make sense for APIs as for browsers, but at least multiplexing can be helpful.
Another thing, that upgrade flow can actually be handy, but it seems to worth another ticket.
I may try to help with it, but I want to finish the support for
uvicornfirst.florimondmanca commentedon Nov 6, 2019
Ah, so the goal is to test the Uvicorn HTTP/2 implementation? 😄 Sounds exciting.
I think there's not a pressing need otherwise to add support for unencrypted HTTP/2, and as you wrote it's probably worth a different ticket spun up from this one.
If you all are OK with it I'll close this, and open one about documenting usage of self-signed certificates. Thanks @gvbgduh!
gvbgduh commentedon Nov 6, 2019
Yeah, I'm happy with it. Thanks @florimondmanca!
I guess those 2 cases (unencrypted traffic within secure net and the upgrade flow) may arise at some point eventually, but not sure it's worth attention now.
indomirreg commentedon May 6, 2020
@florimondmanca any plan to support h2c yet?
Currently, 5G Core works on HTTP2 and as services are behind firewall and load balancer, they communicate using h2c to avoid encryption overload. The goal was to test these services and few implementations are available on h2c.
I am using reverse proxy for http2/TLS -> h2c but this workaround seems unstable. Implementation suggested in #873 would be really helpful
"Second is known as "with prior knowledge". The client does not send a first HTTP/1.1 request but directly sends the request in HTTP/2 format (with frames...) assuming "with prior knowledge" that the server understands the HTTP/2 protocol. All of this without TLS."
Thanks
yeraydiazdiaz commentedon May 7, 2020
Hi @indomirreg, I don't we have plans in the near future to support this, certainly not pre 1.0. But I think we're all in agreement this is something we could look into so I'm reopening this issue.
[-]Force httpx to use HTTP/2 without TLS[/-][+]Support HTTP/2 without TLS[/+]florimondmanca commentedon Aug 8, 2020
A note that this somewhat ties into #304 (connection upgrades), since "unencyprted HTTP/2" via
h2cis an HTTP/1.1 + anh2cupgrade. So it could be that we'd eventually make WebSocket and HTTP/2+h2c use the same "upgrade API" (?).Furthermore, the
h2docs have a handy guide abouth2cupgrades: Negotiating HTTP/2: HTTP URLs (Upgrade).undera commentedon Oct 7, 2020
I also have a usecase where I test microservices from https://github.com/GoogleCloudPlatform/microservices-demo one-by-one. Those microservices don't use TLS due to in-cluster safety.
I should say that
curlalso fails to autodetect HTTP/2 here, but it offers a flag of--http2-prior-knowledge. With the approach of "force http/2", we don't need any complex solutions.What would you say to following proposal: have a third value for
http2flag of Client and AsyncClient, something like this:And have it propagated to
SyncHTTPConnection._create_connection()and its async brother.Does it make sense to you? Any thoughts?
vjache commentedon Apr 30, 2021
Highloaded microservices in a safe cluster, is also my case. HTTP/2 has a greate feature -- multiplexing! One can say "use websocket" but you can't use 'curl' with websocket. So, HTTP/2 with its 'multiplexing' + 'ability to use curl' makes it quite convenient for APIs of highloaded microservices inside safe clusters.
lovelydinosaur commentedon May 3, 2021
So, we ought to support both "Upgrade" and "prior-knowledge" type negotiations.
lovelydinosaur commentedon Feb 2, 2022
We do now support prior-knowledge HTTP/2 (over http or https) with
httpx.Client(http1=False, http2=True).We don't currently support the plaintext
"Upgrade"negotiation.stale commentedon Mar 5, 2022
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
seidnerj commentedon Jul 18, 2023
Any plan to add support for the "Upgrade" negotiation?
lovelydinosaur commentedon Jul 18, 2023
If you would like to make that happen we can help guide you through it.
seidnerj commentedon Jul 19, 2023
Sure, I will update this thread when I have some time to work on this. Thx!
benben002 commentedon May 24, 2024
plan to add support HTTP/2 Cleartext?