Blocking POST request during nested exceptions raising

My script seems (infinitely, more than 12 hours) blocked in a POST request. When I kill it, I get all the nested exceptions below and my feeling it that there is something wrong inside Python requests, do you confirm the problem?
Note that I think I can use GET instead POST but I don't know if it will block too (I'm not sure if POST or GET is more logical for my case).

Thanks in advance!

## Expected Result

Requests should raise an exception instead of infinitely block.

## Actual Result
The POST infinitely block and I get these exceptions after killing the script:
```
2019-07-09 19:05:03,546 [ERROR] Unexpected error when searching new products

Traceback (most recent call last):
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/urllib3/connection.py", line 159, in _new_conn
    (self._dns_host, self.port), self.timeout, **extra_kw)
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/urllib3/util/connection.py", line 80, in create_connection
    raise err
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/urllib3/util/connection.py", line 70, in create_connection
    sock.connect(sa)
OSError: [Errno 101] Network is unreachable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/urllib3/connectionpool.py", line 600, in urlopen
    chunked=chunked)
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/urllib3/connectionpool.py", line 343, in _make_request
    self._validate_conn(conn)
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/urllib3/connectionpool.py", line 839, in _validate_conn
    conn.connect()
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/urllib3/connection.py", line 301, in connect
    conn = self._new_conn()
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/urllib3/connection.py", line 168, in _new_conn
    self, "Failed to establish a new connection: %s" % e)
urllib3.exceptions.NewConnectionError: <urllib3.connection.VerifiedHTTPSConnection object at 0x7f34e5df2cc0>: Failed to establish a new connection: [Errno 101] Network is unreachable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/requests/adapters.py", line 449, in send
    timeout=timeout
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/urllib3/connectionpool.py", line 638, in urlopen
    _stacktrace=sys.exc_info()[2])
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/urllib3/util/retry.py", line 398, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='oceandata.sci.gsfc.nasa.gov', port=443): Max retries exceeded with url: /api/file_search (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f34e5df2cc0>: Failed to establish a new connection: [Errno 101] Network is unreachable'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mount/internal/work-st/apps/download_scripts/nasa-oc-download/nasa_oc_download.py", line 38, in download_products
    checksums_file)
  File "/mount/internal/work-st/apps/download_scripts/nasa-oc-download/nasa_oc_download.py", line 104, in search_new_products
    cur_df = nasa_oc_file_search.search(post_data, split_by_month=True)
  File "/mount/internal/work-st/apps/download_scripts/nasa-oc-download/nasa_oc_file_search.py", line 28, in search
    return split_search(post_data)
  File "/mount/internal/work-st/apps/download_scripts/nasa-oc-download/nasa_oc_file_search.py", line 77, in split_search
    cur_df = simple_search(post_data)
  File "/mount/internal/work-st/apps/download_scripts/nasa-oc-download/nasa_oc_file_search.py", line 35, in simple_search
    data=post_data)
  File "/mount/internal/work-st/apps/download_scripts/nasa-oc-download/throttle.py", line 26, in wrapper
    return fn(*args, **kwargs)
  File "/mount/internal/work-st/apps/download_scripts/nasa-oc-download/nasa_oc_file_search.py", line 49, in nasa_oc_url_request
    response = requests.request(method, url, data=data)
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/requests/api.py", line 60, in request
    return session.request(method=method, url=url, **kwargs)
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/requests/sessions.py", line 646, in send
    r = adapter.send(request, **kwargs)
  File "/mount/internal/work-st/apps/download_scripts/miniconda3/lib/python3.7/site-packages/requests/adapters.py", line 516, in send
    raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='oceandata.sci.gsfc.nasa.gov', port=443): Max retries exceeded with url: /api/file_search (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f34e5df2cc0>: Failed to establish a new connection: [Errno 101] Network is unreachable'))
```

## Reproduction Steps
Not easily reproducible because this happens when the target URL does not respond, but the code is like that (I can give an exemple of <post_data> if needed):
```python
import requests

try:
    response = requests.request('POST', 'https://oceandata.sci.gsfc.nasa.gov/api/file_search', data=<post_data>)
    response.raise_for_status()
except:
    logging.exception('Unexpected error when searching new products')
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.6.1"
  },
  "idna": {
    "version": "2.8"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.3"
  },
  "platform": {
    "release": "3.16.0-30-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "1010102f",
    "version": "19.0.0"
  },
  "requests": {
    "version": "2.21.0"
  },
  "system_ssl": {
    "version": "1010102f"
  },
  "urllib3": {
    "version": "1.24.1"
  },
  "using_pyopenssl": true
}
```

This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).


I don't think this problem is with requests, but a problem with the endpoint. I've tried to make GET and POST requests, neither succeeds. Looking through Google searches, there was a forum post about whether or not it still exists. It might be worth to send an email to NASA to find out if that endpoint still exists.

Thanks for the answer.
On my side the code below works, please can you try too?
But sometimes it infinitely blocks as described in the issue. Do you see something suspect in the nested exceptions listed in the issue?

```python
import requests                                                                                                                                                                                             
r = requests.request('POST', 'https://oceandata.sci.gsfc.nasa.gov/api/file_search', data={'sensor': 'aqua', 'sdate': '2019-03-14', 'psdate': '2019-03-14', 'dtype': 'L2', 'search': 'A*.L2_LAC_OC.nc', 'std_only': 1, 'cksum': 1, 'results_as_file': '1', 'format': 'txt', 'edate': '2019-03-31'})
r.text.split()[:10]                                                                                                                                                                                         
==> 
['477930ff6d542be0c43b305dc8465638eb896f0b',
 'A2019073000000.L2_LAC_OC.nc',
 '75335f52be250047d74d705d1e414f554be08154',
 'A2019073000500.L2_LAC_OC.nc',
 '1f101a3908579d6671686f4fd92b765868020991',
 'A2019073001000.L2_LAC_OC.nc',
 '9ae74c38cadb9d0bb35655a1397290f88aeaf500',
 'A2019073001500.L2_LAC_OC.nc',
 '2721797fa1d23c2c8ba10d3e7461a4e0a6a69d3b',
 'A2019073002000.L2_LAC_OC.nc']
```

Sorry for the late response. Sometimes it works fine for me, sometimes it fails. I think it still might be an endpoint problem, not a problem with requests.

Hi, I don't know if I was clear enough: the problem is not that sometimes the endpoint fail, in this case I should get an exception from requests and it's handled in my code, but sometimes requests seems infinitely blocked on these nested exceptions and I don't get any exception. At this point the only solution I see is implement a timeout around the requests call to kill the call if blocked... I hoped that you could found something suspect in the nested exceptions chain but it seems not the case? Thanks

Hi, I just read in the requests documentation the section about timeouts:
`You can tell Requests to stop waiting for a response after a given number of seconds with the timeout parameter. Nearly all production code should use this parameter in nearly all requests. Failure to do so can cause your program to hang indefinitely.`
So maybe my case is not a bug, sorry but I thought it was not possible that requests wait for answer indefinitely.
I think the timeout arg will solve my problem!
Thanks