SSL configuration API could be improved. #2521
Unanswered
lovelydinosaur
asked this question in
General
Replies: 1 comment
-
|
I'm going to provide some "analogous" discussion reference from |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Our SSL configuration currently uses the following flags:
verify- EitherTrue,False, or a<ca_bundle_path>, or anSSLContext.cert- Either a<cert_file>or a(<cert_file>, <key_file>)or a(<cert_file>, <key_file>, <password>).trust_env- EitherTrueorFalse. EnablesSSLKEYLOGFILE,SSL_CERT_FILE,SSL_CERT_DIR.http2- Sets thealpnprotocols to allow HTTP/2 negotiation.We also have the helper
httpx.create_ssl_context()function available.We have this API because we've followed in the footsteps of
requests, but I find the various overloadings a bit confusing, and I'm not wild about having a whole bunch of different configurations at the top-level, when we could instead define them in a way that more tightly binds them to the scope where they're actually used.I've wondered if we'd provide a better UX if we instead had...
And...
This also makes alternate options more obvious...
Which we can currently do that just fine with
verify=...but it isn't an obvious API to me, given the overloaded meanings.There's some further considerations we'd need to make here:
trust_envis also used elsewhere in the client (proxy config andnetrcconfiguration I think).http2config is also passed through to the default transport.I'm not sure this is worth us moving on, but maybe?...
Beta Was this translation helpful? Give feedback.
All reactions