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
Now we support request payload streaming in a bit reverse way: we could pass a generator as data parameter to client.request() but it makes things harder because of Reverse of Control. Handling back pressure and errors in generator are complicated.
Also sometimes people should pass semi-supported custom request_class for calculating custom headers etc.
Last Trailer headers support #1652 also requires some kind of callback -- which is not elegant at least.
I suggest adding new client.make_request(url, params, headers, ...) method.
The method returns ClientStreamRequest object.
The request is not started at moment of creation but has headers prepared.
User could modify them without subclassing.
The request has .connect() coroutine for connection negotiation (it works with proxies implicitly).
After connection established user calls .send_headers() coro, later .write() coro several times maybe, .send_trailers() if needed and .write_eof(). ClientStreamRequest API should be pretty much close to web.StreamResponse.
All existing client API should be built around ClientStreamRequest calls.
I pretty sure this is viable approach that might make non-trivial usages much simpler than now.
The text was updated successfully, but these errors were encountered:
Now we support request payload streaming in a bit reverse way: we could pass a generator as
data
parameter toclient.request()
but it makes things harder because of Reverse of Control. Handling back pressure and errors in generator are complicated.Also sometimes people should pass semi-supported custom
request_class
for calculating custom headers etc.Last Trailer headers support #1652 also requires some kind of callback -- which is not elegant at least.
I suggest adding new
client.make_request(url, params, headers, ...)
method.The method returns
ClientStreamRequest
object.The request is not started at moment of creation but has headers prepared.
User could modify them without subclassing.
The request has
.connect()
coroutine for connection negotiation (it works with proxies implicitly).After connection established user calls
.send_headers()
coro, later.write()
coro several times maybe,.send_trailers()
if needed and.write_eof()
.ClientStreamRequest
API should be pretty much close toweb.StreamResponse
.All existing client API should be built around
ClientStreamRequest
calls.I pretty sure this is viable approach that might make non-trivial usages much simpler than now.
The text was updated successfully, but these errors were encountered: