1.0 announcement / funding page #1797
Conversation
|
|
||
| ### A sustainable and transparent business model | ||
|
|
||
| Throughout the project we'll be issuing weekly progress reports, to give your businesses confidence that |
There was a problem hiding this comment.
End of sentence missing? :)
There was a problem hiding this comment.
Yeah... it's still in progress in places. 😅
There was a problem hiding this comment.
you should link to the reports: https://www.encode.io/reports/
Certainly helps to lay out the direction, eh? Helpful for me too, since I can see it more clearly, and get priorities in order. |
|
|
||
| HTTPX is the **only** Python HTTP client with **HTTP/1.1 and HTTP/2** support, as well as being the only client providing both **sync and async** support. We'd like to continue pushing the project forward, and we're asking for sponsors to help us in building the foundation of modern HTTP stack for Python. | ||
|
|
||
| We've spent a long time finessing the API for the project, and we're now happy to release a 1.0 version, and provide a standard SEMVER policy on future API updates. |
There was a problem hiding this comment.
I think you should flesh out the stability policy per https://docs.twistedmatrix.com/en/latest/core/development/policy/compatibility-policy.html
and include a separate policy for type hints, and behaviour under adverse conditions such as cancellation
|
|
||
| ### HTTPX 1.3 & beyond... | ||
|
|
||
| Resource limits for the total download time, and maximum allowed download size. Support for WebSockets which run transparently over either HTTP/1.1 or HTTP/2. Documentation for using advanced functionality such as HTTP/2 bi-directional streaming, or working with network streams established using CONNECT or Upgrade requests. Support for a URLLib3 backend, which will aid projects that want upgrade from requests but still keep the underlying networking changes to an absolute minimum. |
There was a problem hiding this comment.
websockets don't run over HTTP/1.1 in the exact same way that HTTP/2 doesn't run over HTTP/1.1
There was a problem hiding this comment.
and they can't run over HTTP/2 https://daniel.haxx.se/blog/2016/06/15/no-websockets-over-http2/
There was a problem hiding this comment.
there also doesn't seem to be any interest in websockets over http3. I suspect because on HTTP 3 EventSource should out-perform websockets.
The new developments are on https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3 that adds "websocket"-like transports with multi homing and datagram support.
There was a problem hiding this comment.
| Resource limits for the total download time, and maximum allowed download size. Support for WebSockets which run transparently over either HTTP/1.1 or HTTP/2. Documentation for using advanced functionality such as HTTP/2 bi-directional streaming, or working with network streams established using CONNECT or Upgrade requests. Support for a URLLib3 backend, which will aid projects that want upgrade from requests but still keep the underlying networking changes to an absolute minimum. | |
| Resource limits for the total download time, and maximum allowed download size. Support for WebSockets which run transparently over either HTTP/1.1 or HTTP/2. Documentation for using advanced functionality such as HTTP/2 bi-directional streaming, or working with network streams established using CONNECT or Upgrade requests. Support for a urllib3 backend, which will aid projects that want upgrade from requests but still keep the underlying networking changes to an absolute minimum. |
There was a problem hiding this comment.
That 2016 blog post is out of date. The websockets-over-http/2 spec is RFC 8441.
There was a problem hiding this comment.
ah indeed it's shipping in chrome and firefox already https://www.chromestatus.com/feature/6251293127475200
There was a problem hiding this comment.
so I'm reading this as websockets can run on their own "compatible with http 1.1" using "http Upgrade" (as opposed to tunnelled 'over http 1.1'), RFC 8441 websockets however are tunnelled over HTTP 2 ?
There was a problem hiding this comment.
Well, it'd probably be a little clearer to say "negotiated transparently over HTTP/1.1 or HTTP/2".
The idea is that upgrading to a raw network read/write API would work equally well against either HTTP/1.1 or HTTP/2, without the developer seeing any difference. Against HTTP/1.1 those read/write operations would map straight onto the TCP connection, but with HTTP/2 they'd map onto a single HTTP/2 stream.
We can achieve this without adding any extra API methods by exposing the stream as an extension.
with client.get(..., headers={"Upgrade": ...}) as response:
if response.status_code != 101:
...
stream = response.extensions["stream"]
...My feeling is that we probably want to tightly scope things, so that we show how HTTPX can be used at this kind of level of API, without necessarily also building a full websockets API on top of HTTPX. (We can leave that to other packages to build on top of.)
| * Fully supports all the features that the `requests` package provides. | ||
| * Both HTTP/1.1 and HTTP/2 support. | ||
| * Strict request timeouts enabled by default. | ||
| * Support for the asyncio and trio concurrency environments. |
There was a problem hiding this comment.
burying the lede here. are you dropping crucio?
|
Maybe something about the performance? |
|
@yjqiang I don't think the phrasing there is properly indicative of the differences, but yes we ought to include DNS caching for the 1.3 release. |
|
Some thoughts here:
|
|
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. |
Starting to flesh out a 1.0 announcement, call for sponsors, and roadmap for future development...