Skip to content

Require pip install httpx[http2] for HTTP/2 support #496

Closed

Description

@lovelydinosaur

I wonder if we should consider having HTTP/2 be an optional requirement, rather than always-on.

I've been working towards minimal installs in other projects eg. Starlette (no hard dependencies) and Uvicorn - we're planning to move towards pip install uvicorn for a basse install of just click and h11, and pip install uvicorn[default] to pull in websockets plus platform specfic stuff like uvloop and httptools. And generally with the other projects in the encode async space too.

We could consider having minimal and default install options with httpx too... eg:

  • pip install httpx - Just http/1.1 support.
  • pip install httpx[defaults] - Also http/2. Potentially http/3 and/or websocket support at a future date. Possible that hsts isn't strictly a hard requirement either.

Any thoughts?

Activity

  1. florimondmanca commented on Nov 2, 2019

    @florimondmanca
    Contributor

    I think having a consistent policy wrt installs across Encode projects is a neat idea. Minimal installs + <project>[default] for regular/enhanced features sounds good to me!

  2. florimondmanca commented on Dec 4, 2019

    @florimondmanca
    Contributor

    Seeing #584, we could consider multiple extras, i.e. one per extra feature:

    pip install httpx[http2]
    

    And in the future, possibly…

    pip install httpx[http2,websocket,http3,...]
    
  3. changed the title [-]Minimal installs[/-] [+]Require `pip install httpx[http2]` for HTTP/2 support[/+] on Dec 6, 2019
  4. lovelydinosaur commented on Dec 6, 2019

    @lovelydinosaur
    MemberAuthor

    Retitling this to specifically reflect what we'd like to do for HTTP/2.

    I had a look at it this morning, and it's actually not as easy as I'd expected to only lazily import the HTTP2Connection.

    • Really we want a base EstablishedConnection type, that provides base interface the both HTTP2Connection and H11Connection implement.
    • That way the HTTPConnection class can hold a connections of the type Optional[ActiveConnection], rather than specifically having the H2Connection and H11Connection types.

    However, right now we're blocked by the proxy implementation reaching directly into the H11 implementation. See #604.

    We'd need to switch things around so that the connection classes are responsible for implementing a start_tls method, which the proxy implementation can then call into.

  5. lovelydinosaur commented on Dec 31, 2019

    @lovelydinosaur
    MemberAuthor

    I'm going to suggest we drop this. Any thoughts?

    Our HTTP/2 implemenentation has greatly improved, and even tho it's currently not enabled by default I could see us switching that once we judge it to be sufficiently mature. I'm no longer convinced that "minimal installs" are worth the additional hoop for users to jump through and codebase complexity.

  6. florimondmanca commented on Dec 31, 2019

    @florimondmanca
    Contributor

    Yup, agreed after our discussions on #639. The off-by-default behavior is probably sufficient as a "this is edge stuff" flag. At least having it off by default protects our users from dealing with HTTP/2 issues when all they want is to make HTTP requests, regardless of HTTP/1.1 vs HTTP/2.

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

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions