Client request timeout parameters are inconsistent

[ykshatroff]

Long story short

The behavior of the read_timeout argument of ClientSession constructor and the timeout argument of ClientSession.request() method is inconsistent and prevents use of ClientSession.read_timeout in requests by default.

Expected behaviour

Passing read_timeout to ClientSession constructor makes the passed value the default timeout for every session request (i.e. when no timeout argument is passed to session.request()),
as well as passing timeout=None explicitly to session.request() disables the timeout.

Actual behaviour

In the docs, it's stated that timeout=None passed to session.request() disables the timeout. Instead, it forces the use of session's default timeout.

Moreover, the session's read_timeout is effectively unused by default, instead the DEFAULT_TIMEOUT (5*60) is used. To enable the session's read_timeout for requests, we must pass timeout=None explicitly to every request, which in turn contradicts to the meaning of None as completely disabling the timeout.

This behavior is very inconvenient and error-prone, allowing for the situation where we are unexpectedly left without any timeout (when we don't pass a read_timeout to ClientSession and pass a timeout=None to reqeust() in order to get the read_timeout into effect).

Steps to reproduce

In this code, the effective timeout is not 0.01 but 5*60:

session = ClientSession(read_timeout=0.01)
session.get("https://google.com")

In this code, the effective timeout is 0.01 instead of no timeout:

session = ClientSession(read_timeout=0.01)
session.get("https://google.com", timeout=None)

In this code, there is effectively no timeout at all, though one could think naively that omitting read_timeout in session constructor effects in some default timeout being used:

session = ClientSession()
session.get("https://google.com", timeout=None)

Your environment

This issue is relevant to any aiohttp==2.0.7 setup.

[fafhrd91]

thanks for PR!

[lock]

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.