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
{{ message }}
Repository navigation
Require pip install httpx[http2] for HTTP/2 support #496
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.
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!
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.
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.
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.
Activity
florimondmanca commentedon Nov 2, 2019
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!florimondmanca commentedon Dec 4, 2019
Seeing #584, we could consider multiple extras, i.e. one per extra feature:
And in the future, possibly…
[-]Minimal installs[/-][+]Require `pip install httpx[http2]` for HTTP/2 support[/+]lovelydinosaur commentedon Dec 6, 2019
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.
EstablishedConnectiontype, that provides base interface the bothHTTP2ConnectionandH11Connectionimplement.HTTPConnectionclass can hold a connections of the typeOptional[ActiveConnection], rather than specifically having theH2ConnectionandH11Connectiontypes.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_tlsmethod, which the proxy implementation can then call into.lovelydinosaur commentedon Dec 31, 2019
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.
florimondmanca commentedon Dec 31, 2019
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.