-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API for streaming HTTP client bodies. #242
Comments
Hello @jeffutter
For servers, // https://c410-f3r.github.io/wtx/http2/index.html
Passes the hpack-test-case and the h2spec test suites. Due to official deprecation, server push and prioritization are not supported. For clients,
Contrary to HTTP/1, an HTTP/2 connection can live indefinitely so when a stream is opened, both parts can theoretically transfer as much data as needed. One caveat is that this interaction is an "one-shot" semiduplex-like (https://en.wikipedia.org/wiki/Duplex_(telecommunications)) scenario. I have a feeling that you looking for a full-duplex communication between the client and the server. If that is the case, then WebSockets over HTTP/2 streams should be enough (https://datatracker.ietf.org/doc/html/rfc8441). Unfortunately Another thing worth mentioning is the fact that Cheers |
Thanks for the quick reply. I should have provided some examples of what I'm asking about for clarity as some of the terms (like "stream") are pretty overloaded. I'm looking for unidirectional communication where the client can read bytes of the response before the full response has been delivered. A common example might be 'streaming' a video file. You have one request to the server and one response, but you don't have to wait until the entire file is downloaded before you can do anything with it.
What I'm looking for is more like FWIW, my actual use-case is to implement a client for Apollo GraphQL's http-multipart graphql subscriptions since they don't support subscriptions over Websockets. Hope this clears up the ask. Thanks! |
Thank you for the clarification.
Yeah, that is correct. All data must be available in advance. The underlying machinery automatically splits the data according to https://datatracker.ietf.org/doc/html/rfc9113#SETTINGS_MAX_FRAME_SIZE and sends each block concurrently respecting flow control parameters. This approach is pragmatic but lacks flexibility, as you noticed.
Oh, I see. Fine-grained or "low-level" stream operations weren’t added because no one asked until now :) I plan to add this new functionality in the next version of |
Hi there,
Very interested in what you are doing here with
wtx
.I was wondering if there is support for streaming HTTP response bodies?
I see
ClientStream.recv_res
, but that says.which is not what I want.
It does indicate "Higher operation", but I can't really seem to find any lower-level client APIs to create a request and stream the response body.
I'm wondering if I'm overlooking something here. Or, if it doesn't exist, are there plans to add such APIs?
The text was updated successfully, but these errors were encountered: