-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Description
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.