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.
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 customrequest_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 returnsClientStreamRequest
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.