Open sta4152 opened 3 months ago
If you want us to look at this, you'll probably have to create a test (e.g. in test_proxy.py or test_proxy_functional.py) that demonstrates the issue.
Sorry, I am no python dev.
I understand the if
statement from the report (and the code from the stacktrace), but I am not in the position to author a test for testing this within your framework.
Well step 1 of your reproducer pretty much rules out the chance of anybody looking at this..
Sorry again, I am just the indirect user of that library. And this is the only option for me to reproduce it.
But if you have a look to the we narrowed it down to
, then it is obvious, that with this if
condition from you libraries code, the proxy is used for all destinations, without considering the additionally configured no_proxy
(AFAIR you even have a utilities method for checking, if for a url the proxy should be used and that considers the no_proxy
settings, but it is "just" not used there).
It may happen, that with having fixed it there, this may not be sufficient from top-level point of view (kubernetes cluster), yet. But you shoud be in the position to crete a test for that mentioned piece of code and verify my report for that (that me, as said not being a python dev, is not able to create).
But you shoud be in the position to crete a test for that
To put that into context, this project is over a decade old and written by hundreds of contributors. Speaking for myself, I have never even used the proxy functionality in this project, nevermind written any of it. I have no idea how this NO_PROXY envvar is supposed to work (searching for it in the code shows a mention in the docs and a couple of tests in test_helpers.py, but no reference in the code itself), and don't know how to verify this behaviour.
I'm just telling you what needs to happen to significantly increase your chances of someone else looking at the issue. Unless an issue is directly affecting a maintainer (who is a volunteer with limited time), it's unlikely that they will spend hours trying to figure out your problem. If you can provide a test (or failing that, a copy/paste reproducer that can be immediately run locally), there is a good chance someone will look at fixing it. If not, chances are slim.
Describe the bug
We try to connect to a kubernetes cluster, residing behind a proxy that is needed for downloading external resources, but not for connecting to the cluster. In the proxy log we observe access to
10.152.183.1:443
, which is the cluster's api server, and whose network is excluded using no_proxy/NO_PROXY environment. We narrowed it doen to (at least) https://github.com/aio-libs/aiohttp/blob/a561fa990427383358b19dc1eabc968e03a95413/aiohttp/connector.py#L928Here it is asked only, if there is set a proxy. Not considering the target to establish the connection to. And thus not considering the exclusion for the k9s api server address.
To Reproduce
You should be able to test much easier, here is just what we used for testing:
10.152.183.0/24
(with default k9s networking)Expected behavior
The proxy must not be accessed for addresses mentioned in no_proxy/NO_PROXY
Logs/tracebacks
Python Version
aiohttp Version
multidict Version
yarl Version
OS
Linux testing-0 5.15.0-116-generic #126-Ubuntu SMP Mon Jul 1 10:14:24 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Related component
Client
Additional context
No response
Code of Conduct