You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we should drop per-request cert/verify on the client methods, and only allow them on the client itself.
The reasoning for this is that you don't know when you make a request on the client if you'll actually acquire (and verify) a connection, or if you'll end up re-acquiring a connection (without any verification).
Really the configuration ought to always just be per-connection-pool, rather than per-request.
Dropping these two would also mean removing them from the dispatcher API, which feels cleaner as a result.
We can leave them on the top-level standalone functions, since they apply to the client in that case anyways.
I'd be interested in seeing this happen! It always felt strange to me that these particular two parameters were part of the dispatcher API. To reinforce your point, IMO the use case of verifying/not verifying or using different certs for different requests is narrow enough, and is already supported by the ability to instantiate multiple clients.
Activity
florimondmanca commentedon Nov 29, 2019
I'd be interested in seeing this happen! It always felt strange to me that these particular two parameters were part of the dispatcher API. To reinforce your point, IMO the use case of verifying/not verifying or using different certs for different requests is narrow enough, and is already supported by the ability to instantiate multiple clients.
[-]Drop per-request `cert`/`verify`[/-][+]Drop per-request `cert`/`verify`/`trust_env`[/+]