Multiple requests on a single Session with different client certs behave incorrectly

Consider the following code:

``` py
import requests

s = requests.session()
s.get("https://host", cert="path/to/cert1.pem")
s.get("https://host", cert="path/to/cert2.pem")
```

`requests` will silently reuse the same connection for both connections, which is incorrect.


Yeah, this is not good. We have a similar problem if a user switches the 'verify' flag as well, so we need to fix that.


So, @shazow, I think really we need to adjust the connection pooling logic in urllib3 a bit. Keying connections off the URL isn't really enough: for HTTPS connections we need to key them off the various connection state parameters as well (cert_reqs, ca_certs, ca_cert_dir, client cert parameters). That's pretty gross because it's a major API change.

Thoughts?


Hm I think we had this discussion before somewhere and the conclusion is that we need to avoid exposing per-request cert configs?


Maybe we need to make the PoolManager keying more configurable in general, though?


I think I'm hitting the same problem where I want to change the auth between requests, but it looks like the first set of credentials gets used for all requests.


Yup, this is a known issue. It's on my list to fix, but don't expect the fix to be soon. =)


is there a workaround?

On Wed, Nov 25, 2015 at 10:33 AM, Cory Benfield notifications@github.com
wrote:

> Yup, this is a known issue. It's on my list to fix, but don't expect the
> fix to be soon. =)
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/kennethreitz/requests/issues/2863#issuecomment-159642250
> .


The best workaround at this time is to avoid using a Session or, if you are using one of the non-connection-pooling features of the Session, to run a TransportAdapter that never pools connections.


I'm using the Session to track cookies. I'll look into alternate
TransportAdapters, thanks.

On Wed, Nov 25, 2015 at 10:37 AM, Cory Benfield notifications@github.com
wrote:

> The best workaround at this time is to avoid using a Session or, if you
> are using one of the non-connection-pooling features of the Session, to run
> a TransportAdapter that never pools connections.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/kennethreitz/requests/issues/2863#issuecomment-159643426
> .


Would it be possible to add this limitation to the docs? I lost several
hours of work debugging this today.
El 25 nov. 2015 10:39, "Chris AtLee" chris@atlee.ca escribió:

> I'm using the Session to track cookies. I'll look into alternate
> TransportAdapters, thanks.
> 
> On Wed, Nov 25, 2015 at 10:37 AM, Cory Benfield notifications@github.com
> wrote:
> 
> > The best workaround at this time is to avoid using a Session or, if you
> > are using one of the non-connection-pooling features of the Session, to run
> > a TransportAdapter that never pools connections.
> > 
> > —
> > Reply to this email directly or view it on GitHub
> > https://github.com/kennethreitz/requests/issues/2863#issuecomment-159643426
> > .


We could do, but I think it'd be better long-term if we made a move to fix it instead.


@catlee My gift to you is the first part of the work required for this: shazow/urllib3#751.


Hi all. I would be very excited if this particular issue got resolved and would be more than willing to contribute my time to make that happen. I've spent a bit of time poking around in both urllib3 and requests, but I'm still pretty new to both libraries.

Is the plan to get https://github.com/shazow/urllib3/pull/751 into a satisfactory state and then refactor the `requests.adapters.HTTPAdapter` to use the new API? It seems like the urllib3 pull request is stalled because of design uncertainty, so I'm not sure there's a lot I can do there (especially since I don't really know what I'm doing yet). Is there anything else I can do to help?


Yeah, essentially that's the plan. Last I checked, I think @shazow and I were unclear on exactly the direction that change should take.


I just ran into this and struggled at some length.  Here's a quick doc change to prevent others from suffering the same fate: https://github.com/kennethreitz/requests/pull/3200


This should be fixed by #3109. Once that's done, we can close this out.


Should this be closed now?

Yep, it looks like Jeremy's kw work solved this. Thanks for pinging @alex!