urllib3 closes the underlying connection when we call
urllib3.Response.close but does not release it back to the connection
pool. This can cause issues when users have a blocking connection pool
configured and connections are not readily returned to the pool.
Since the underlying connection is closed, we should be able to safely
return the connection to the connection pool, so to fix this issue we
merely need to not return after closing the response.
Closes gh-3461
* BaseAdapter definition of send is missing mandatory params
* Copy over relevant parts of the interface documentation
* Indentation fix
* Change base class documentation for close
It seems it's necessary both in pulling all_proxy from the environment
(rebuild_proxies) and deciding which proxy to use (select_proxy).
Also added new functional test.
Previously we checked that the `request` being sent was an instance of a
PreparedRequest. If a user somehow created a PreparedRequest using a different
Requests library instance, this check makes the request un-sendable.
(This happened recently - unbeknownst to me, my server was running an outdated
version of pip, vulnerable to this issue - pypa/pip#1489, which creates
multiple subdirectories (src/requests, src/requests/requests) when you rerun
pip install --target. So the PreparedRequest was being created in one version
of the library and compared against the other version of the library, and
throwing this exception, even though they were both PreparedRequest instances!)
It would probably be preferable to check the object's behavior (instead of
its type), but a PreparedRequest has a lot of behavior, and it wouldn't be
really feasible or allow us to provide a helpful error message to check all
of it here. Instead flip the conditional to guard against the user sending an
unprepared Request, which should still give us most of the benefits of the
better error message.
Fixes#3102
Nate Prewitt
kennethreitz