Skip to content

Support HTTP/2 without TLS #503

Closed
Closed

Description

@gvbgduh

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.

Activity

  1. lovelydinosaur commented on Nov 4, 2019

    @lovelydinosaur
    Member

    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.

  2. sethmlarson commented on Nov 4, 2019

    @sethmlarson
    Contributor

    @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.

  3. gvbgduh commented on Nov 4, 2019

    @gvbgduh
    Author

    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.

  4. florimondmanca commented on Nov 6, 2019

    @florimondmanca
    Contributor

    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?

  5. added
    http/2Issues and PRs related to HTTP/2
    tls+pkiIssues and PRs related to TLS and PKI
    on Nov 6, 2019
  6. gvbgduh commented on Nov 6, 2019

    @gvbgduh
    Author

    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.

  7. florimondmanca commented on Nov 6, 2019

    @florimondmanca
    Contributor

    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!

  8. gvbgduh commented on Nov 6, 2019

    @gvbgduh
    Author

    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.

  9. indomirreg commented on May 6, 2020

    @indomirreg

    @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

  10. yeraydiazdiaz commented on May 7, 2020

    @yeraydiazdiaz
    Contributor

    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.

  11. changed the title [-]Force httpx to use HTTP/2 without TLS[/-] [+]Support HTTP/2 without TLS[/+] on May 7, 2020
  12. added this to the v1.1 milestone on Jul 30, 2020
  13. florimondmanca commented on Aug 8, 2020

    @florimondmanca
    Contributor

    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" (?).

    Furthermore, the h2 docs have a handy guide about h2c upgrades: Negotiating HTTP/2: HTTP URLs (Upgrade).

  14. undera commented on Oct 7, 2020

    @undera

    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?

  15. vjache commented on Apr 30, 2021

    @vjache

    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.

  16. lovelydinosaur commented on May 3, 2021

    @lovelydinosaur
    Member
  17. lovelydinosaur commented on Feb 2, 2022

    @lovelydinosaur
    Member

    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.

  18. stale commented on Mar 5, 2022

    @stale

    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.

  19. seidnerj commented on Jul 18, 2023

    @seidnerj

    Any plan to add support for the "Upgrade" negotiation?

  20. lovelydinosaur commented on Jul 18, 2023

    @lovelydinosaur
    Member

    If you would like to make that happen we can help guide you through it.

  21. seidnerj commented on Jul 19, 2023

    @seidnerj

    Sure, I will update this thread when I have some time to work on this. Thx!

  22. benben002 commented on May 24, 2024

    @benben002

    plan to add support HTTP/2 Cleartext?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    http/2Issues and PRs related to HTTP/2tls+pkiIssues and PRs related to TLS and PKIwontfix

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions