Requests fails to get a particular resource in python2, but not urllib

I am trying to obtain a resource with requests, it timeouts in python2, but succeeds in python3. Using urllib2/urllib, it works fine.

## Expected Result

No particular problem in python2, it's just a GET.

## Actual Result

It never finishes in python2.

## Reproduction Steps

```python

import re
import sys

import requests
import six


USE_REQUESTS = False


def do_get(url):
    if USE_REQUESTS:
        headers = {
            'User-Agent': 'Mozilla',
        }
        return requests.get(url, headers=headers).content

    if six.PY2:
        import urllib2 as urlmodule
    else:
        import urllib.request as urlmodule

    req = urlmodule.Request(url)
    req.add_header('User-Agent', 'Mozilla')
    return urlmodule.urlopen(req).read()


def run():
    path = re.search(
        r'"(dciweb.png[^"]+)"',
        do_get('https://reunion.bnpparibas.net/part/fr/dciweb.htm?p0=idesai.tht&t=p').decode('iso8859-1')
    ).group(1)
    path = path.replace('amp;', '')

    do_get('https://reunion.bnpparibas.net/part/fr/' + path)


if sys.argv[1:2] == ['-r']:
    USE_REQUESTS = True

run()
print('OK')
```

(Pass `-r` to use `requests`, else `urllib2/urllib`)

* Run these 4 different ways
```
python3 req.py  # prints OK
python2 req.py  # prints OK
python3 req.py -r  # prints OK
python2 req.py -r  # does not work!
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": "2.6.1"
  }, 
  "idna": {
    "version": "2.6"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.16"
  }, 
  "platform": {
    "release": "4.18.0-2-amd64", 
    "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 should probably be closed since Python 2.x is now end-of-life.

@tommorris Requests still supports Python 2. That said, there are extra circumstances here including "which request is failing or where is this stuck?" I could easily see that `str.replace` and a greedy regular expression could prevent something from terminating here. There's no evidence in the report that this is strictly requests.

Over a year later, and I expect this person figured their problem out. Probably with the help of StackOverflow which was the right place to post this in the first place.

@sigmavirus24 @tommorris 

> Over a year later, and I expect this person figured their problem out. Probably with the help of StackOverflow which was the right place to post this in the first place.

No, the problem is still here. requests still has a bug, and requests' code didn't fix itself magically.

However, I moved on, that's right. Given the lack of responsiveness here, I gave up waiting for a hypothetical fix that would never come, I ended up using urllib2 for accessing that site rather than requests, since requests is just buggy here, as demonstrated.

> However, I moved on, that's right. Given the lack of responsiveness here, I gave up waiting for a hypothetical fix that would never come, I ended up using urllib2 for accessing that site rather than requests, since requests is just buggy here, as demonstrated.

You haven't actually proven this is a bug in Requests. Also, mature projects don't need to be immediately responsive. And on top of that, I just became involved again in this project, so taking your anger out here is inappropriate

> You haven't actually proven this is a bug in Requests.

How can I know if it comes from requests or the lower layers? I observe a consistent behavior so it doesn't come from elsewhere than the requests stack. I can't investigate deeper, that's why I'm reporting the bug. If I already knew where the bug came from, I wouldn't report something waiting forever, I would just patch it myself.

You're the requests developer, not me. It makes no sense to ask me to find out if it's requests or lower that fails. Users are expected to report bugs to the layer they can. Users are not expected to investigate all the code until the OS, else they wouldn't be users.

> And on top of that, I just became involved again in this project, so taking your anger out here is inappropriate

It's not my first awful experience with the requests developers. Every single bug I've reported to this project has been welcomed with the same level of inappropriateness as this one, something like "meh, we don't want to look at it" or "meh, it's too hard to fix, so we'll just keep the bug" or "meh, we don't need to respect RFCs".
So I guess there's some sort of culture of doing the least possible in the whole project.

> You're the requests developer, not me. It makes no sense to ask me to find out if it's requests or lower that fails. Users are expected to report bugs to the layer they can. Users are not expected to investigate all the code until the OS, else they wouldn't be users.

Servers respond differently to urllib2 and requests meaning that the response in Python 2 for the first request could lead your greedy and inefficient Regular expression to "never" complete. Cancelling this and showing a stack trace within requests is a step towards saying this is happening, or changing your code to include more debugging. There's plenty you can do to show "this stops in requests".

> Every single bug I've reported to this project has been welcomed with the same level of inappropriateness as this one

If you feel I've been inappropriate, please report me to the PSF for a Code of Conduct violation. I'll look for your other [issues](https://github.com/psf/requests/issues?q=is%3Aissue+author%3Ahydrargyrum+), but somehow, I doubt you were given those responses. Regardless, this thread isn't productive, so I'm walking away