-
Notifications
You must be signed in to change notification settings - Fork 278
Investigate switching to urllib3 #2751
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Documenting findings from the PR:
|
For historical reference:
Why we are (kind of) reversing that decision now:
|
Actually, looking further into this: urllib3 does not "automatically" handle the proxy related env variables at least. hmmm... Basic support for http proxy variables is not that tricky -- legacy urllib contains code that parses all the variables so we'd just have to choose a proxy based on them -- but it's not something I'd like to do in python-tuf |
I've talked to Seth Larson (urllib3 dev): they've made a conscious decision to not handle proxy variables -- this is understandable for them but puts this project in a bit of a pickle... urllib3 is so close to doing everything we need but not quite there. I think loads of users are behind dumb corporate proxies and their only way to get software working is proxy variables: I don't think we can just hand wave the issue away. I think we have two choices:
As an experiment I've handled what I think are the sensible parts of proxy variables in ~70 lines of code: this feels acceptable. but would need tests etc still. |
Uh oh!
There was an error while loading. Please reload this page.
We currently use requests in the default ngclient fetcher (RequestsFetcher).
Internally requests uses urllib3 and we don't seem to use any functionality outside of what urllib3 provides: connection pool management and streaming are supported. Switching to urllib3 would mean:
This could be achieved by first writing an alternative FetcherInterface implementation that uses urllib3: if it looks good we can then make it the default and remove the requests-based implementation.
The text was updated successfully, but these errors were encountered: