connection with retry=0 is retried

We have a celery task, where we just ping emailing service to send an email. We use requests for that with following params:
```
CONNECTION_TIMEOUT = 3
READ_TIMEOUT = 26
DEFAULT_TIMEOUT = (CONNECTION_TIMEOUT, READ_TIMEOUT)
...
DEFAULT_MAX_REQUEST_RETRIES = 0
```
we then initialize session with `timeout=DEFAULT_TIMEOUT` and when firing GET request, we pass `max_retries=0`.

On celery side, we set `soft_time_limit=(emailing.CONNECTION_TIMEOUT + emailing.READ_TIMEOUT + 2) * (1 + DEFAULT_MAX_REQUEST_RETRIES)`, which amounts to 31 seconds (29 for possible timeouts and 2 seconds for extra room/processing). But yesterday we saw `SoftTimeLimitExceeded` being raised from this task. Looking into logs, I can see the request was retried:
```
Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ReadTimeoutError("HTTPConnectionPool(host='our_host.example.com', port=30303): Read timed out. (read timeout=26)",)': /data/{path}
```
I found log warning in the code of urllib3:
```
if not conn:
    # Try again
    log.warning(
        "Retrying (%r) after connection broken by '%r': %s", retries, err, url
    )
    return self.urlopen(
```
So after a timeout of 26 seconds, we should finish the celery task, but urllib3 is retrying after a broken connection and we hit the limit in async worker. 

## Expected Result

I expect requests retry only number of times specified in `max_retries`

## Actual Result

Broken connections are retried

## Reproduction Steps

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "3.4.7"
  },
  "idna": {
    "version": "2.10"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.9"
  },
  "platform": {
    "release": "20.3.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "101010bf",
    "version": "20.0.1"
  },
  "requests": {
    "version": "2.25.1"
  },
  "system_ssl": {
    "version": "101010af"
  },
  "urllib3": {
    "version": "1.26.4"
  },
  "using_pyopenssl": true
}
```


> we then initialize session with `timeout=DEFAULT_TIMEOUT` and when firing GET request, we pass `max_retries=0`.

Based on what you describe here either you're not using Requests and are using something that wraps requests - in which case, I'm certain this is their bug - or you're attempting something this library does not in reality support.

https://github.com/psf/requests/blob/b227e3cb82c8d42ea27790d615ecafe12528d3bc/requests/sessions.py#L362-L422 shows that there is no session level timeout setting (as searching closed issues will also show you) and there's no Session-level retries configuration. Without any semblance of code to reproduce this, I'm going to close this since I cannot fathom what you're trying to convey above

oh right, sorry about that. Yes we use [wrapped requests](https://github.com/kiwicom/request-session), where [max_retries is just while cycle](https://github.com/kiwicom/request-session/blob/master/request_session/request_session.py#L314) and timeout is passed as param to [session.request()](https://github.com/kiwicom/request-session/blob/master/request_session/request_session.py#L446).  

So I should have asked, how come the `send()` method on the session object can take longer than the  specified timeout? Twice as long.

> So I should have asked, how come the `send()` method on the session object can take longer than the specified timeout? Twice as long.

If you search open and closed issues, this would become apparent. The short answer is the following: the `read` timeout isn't a wall clock timeout. In all likelihood, we're issuing a `read` and the server is sending back some data at a trickle. So maybe there's N seconds where the data sends back a few bytes at a time - that resets the read timeout. So you might even have a server that trickles data back for 26 seconds or 30s or even several minutes and then stops sending data. The last byte it sends starts the 26s timeout. It's not "26s for the whole read". It's "26s of no data being sent".

Oh, ok. Thanks for the explanation and sorry if it was explained before. I was searching issues for that log message + our custom retries confused me, I naively thought this was a simple use case that is supported in requests. Thanks again.

It's not easy to support a wall clock timeout in python across all supported operating systems. Heck our tests still get people reporting they don't run on extremely esoteric bit sets and architectures. We're in a rough spot to be able to support this use case beyond what the standard operating system behavior is