-
Notifications
You must be signed in to change notification settings - Fork 66
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
HTTP client ignores "no_proxy" environment variable #163
Comments
Missed to share the server logs:
|
Thanks for the detailed issue description! It's true there's no handling for a In the meantime I will look at some very basic logic for checking that list. |
@genzgd, thank you very much for fixing. I can confirm it works now as expected. I have updated my python dependency to |
Thanks for the update, much appreciated. |
Describe the bug
clickhouse-connect
seems to ignore the environment variableno_proxy
/NO_PROXY
in a local Apache Superset configuration via Windows 10 with Docker Desktop and WSL2.Utilizing a configuration that requires a forward proxy (e.g. in a corporate network) creates the need to maintain
HTTP_PROXY
/HTTPS_PROXY
environment variables to allow Apache Superset to download Python packages like theclickhouse-connect
driver and sample data. This may eventually need to provide additional SSL certificates and to set corresponding environment variables for Python and Node.JS (details on the configuration below - no issue in this context).In the particular scenario described below a local
Fiddler
forward proxy is used, however the used proxy does not seem to matter and is just relevant for the text of the error message.Installing the
clickhouse-connect
driver and connecting to clickhouse via connection stringclickhousedb://default:@clickhouse:8123
should work, given the clickhouse container was namedclickhouse
respectively without leaving the local docker network. When trying to connect to the database, there is the following error message:The error message indicates that the local docker network was left and the request to host
clickhouse
was sent to the forward proxy. This is ignoring the setting in environment variableno_proxy
, which did contain hostclickhouse
as the exception.Workaround:
Docker compose creates a default network to bridge to the host. As per the clickhouse settings described above, the container is exposed on a port on the host OS, hence connecting via string
clickhousedb://default:@localhost:8123
does work. This is considered sub-optimal since a later production setup should isolate the database, while allowing to install the database driver. This would require proper handling of proxy settings and avoid to reroute via the forward proxy when connecting to the database.Other considerations:
Connecting to
clickhousedb://play:[email protected]:443
as suggested here does work as a sanity check of the proxy and certificates setup. The external URL is recognized by the forward proxy, while the container/service nameclickhouse
is not and leads to an error.Steps to reproduce
Setup Apache Superset in Windows 10 with Docker Desktop with WSL2 support as described here
Add
clickhouse
container todocker-compose-non-dev.yml
(add the following in the respective sections):Add
clickhouse-connect>=0.4.1
to./docker/requirements-local.txt
as described here and hereAdd proxy setup to
.docker/.env-non-dev
(add the following to the file):Start the containers via
TAG=1.5.3 docker-compose -f docker-compose-non-dev.yml up
Log in to
http://localhost:8088/
Add clickhouse database as described here
Expected behaviour
Connection string
clickhousedb://default:@clickhouse:8123
and clicking "Test Connection" should allow successful connectivity to the database.Code example
The code of
clickhouse-connect
indicates support for the proxy environment variables, but not for theno_proxy
exception list:clickhouse-connect/clickhouse_connect/driver/__init__.py
Lines 65 to 66 in b1c78f8
clickhouse-connect and/or ClickHouse server logs
Configuration
Environment - from within the
superset_app
container:Clickhouse Server on Version 23 (see docker compose file).
The text was updated successfully, but these errors were encountered: