With the addition of https://github.com/shazow/urllib3/pull/830 requests
should update the connection_pool_kw on the PoolManager so that new
ConnectionPools get created when TLS/SSL settings change. This ensures
that users can update the CA certificates used to verify servers as well
as the client certificate and key it uses to authenticate with servers.
This fixes issue #2863
Verify that the expected warnings are emitted
with SubjectAltNameWarning emitted on all environments
due to the https server provided by httpbin_secure.
So that failing tests don't cause the server thread to hang
indefinitely, waiting for connections that will never come.
Rationale for suppressing error/traceback from interrupted
_accept_connection in testserver.Server:
https://gist.github.com/brettdh/b6e741227b2297f19d2118077f14dfa5
* Move server socket close to just before join
This way it handles the no-connections, no-exceptions case
as well as the exception case. If the server thread doesn't
exit by itself within 5 seconds of the context manager exit,
the accept will be interrupted.
* Address feedback
- pytest.raises rather than except:pass
- Move socket create/bind back to run()
- Timeout on accepting connections
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
Ian Cordasco
kennethreitz