-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
allow unique connect + read timeouts #1524
Comments
Thanks for this! |
status is waiting on someone to approve + merge my change. Unfortunately/fortunately I don't have perm ;) |
merged |
@thehesiod So if I understand #1523 correctly, passing |
passing None for timeout will result in using the underlying TCPConnector's connect |
i refactored how client handle timeouts.
request timeout == "time to open connection" + "time to send request" + "time to read all data from response" |
Long story short
aiohttp should allow users to easily support unique read + connector timeouts
Actual behaviour
Currently you can set a connect timeout by overriding the TCPConnector.
Currently to specify a read timeout you need to either pass a timeout parameter to ClientSession.request (this timeout is used for both the read_timeout [https://github.com/KeepSafe/aiohttp/blob/master/aiohttp/client.py#L173] and the connector timeout [https://github.com/KeepSafe/aiohttp/blob/master/aiohttp/client.py#L175]), potentially overriding the TCPConnector's timeout, or you need to subclass the response_class and it's init method...and specify a max of read_timeout + connect_timeout to ClientSession.response timeout parameter.
So basically the ClientSession.request timeout is overloaded to clamp existing read_timeout and existing conn_timeout making it complicated for clients. Instead I think clients would mostly want to set the read/conn timeout on the Session and not worry about each request's timeout.
Discussion for resolution
There are a variety of ways to potentially solving this:
I think ideally the ClientSession would have an init-able read_timeout, and the existing request_timeout can be treated as a wrapped max timeout.
thoughts? btw this is discussed in part in #1180
initial attempt at fixing this issue via idea 2: #1523
The text was updated successfully, but these errors were encountered: