feat: honor http_proxy environment variables
#1111
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1111 +/- ##
==========================================
- Coverage 82.68% 82.56% -0.13%
==========================================
Files 53 53
Lines 7930 7942 +12
Branches 1240 1246 +6
==========================================
Hits 6557 6557
- Misses 1263 1270 +7
- Partials 110 115 +5 |
src/sentry_core.c
Outdated
| if (options->read_proxy_from_environment) { | ||
| sentry__set_proxy_from_environment(options); | ||
| } |
There was a problem hiding this comment.
With this new option, I'm not sure we still need to support no_proxy; if users want to use the environment variable value in their own code, they can just not set this flag to true (which is the default anyway).
There was a problem hiding this comment.
Yes and no. You always have to consider that this is a feature that the users of our users require from them.
So, for instance, if your application ignores the http_proxy env-vars, your users don't care about the topic and accept that they have to manually configure the proxy config for that application (or even have no proxy config at all).
At some point, you might provide a UI to your users that does something like the following:
( ) direct HTTP connection.
( ) manually specify HTTP proxy: _________ .
( * ) read proxy from the environment.
You can route this directly to our proposed options interface. However, once your users have configured the app to read from the environment, they will want to stay with it because it allows them to have a centrally managed proxy configuration rather than defining it separately in every application.
This is where no_proxy enters the picture. So, yes, resetting the proxy config of that app solves the problem, but then the users of our users are essentially back to square 1. Again, this is not a requirement for an initial implementation of that feature but a likely follow-up.
|
We still need to find a way to work around WinINet bypassing the localhost->localhost proxy in our test environment. Locally this was tested by adding a line to the Windows hosts file |
|
Also, now that we test whether the proxy actually gets used when we prompt it to, this crashpad socks5-proxy test fails on macOS (see runner output). It seems like the proxy isn't used, but when trying this with a non-localhost DSN it seems to work (similar to the remaining Windows failures)). |
- wrong bc of localhost-to-localhost proxy ignore in macOS
| @@ -11,3 +11,5 @@ leak:SCDynamicStoreCopyProxiesWithOptions | |||
| # This is a known issue in ASAN packaged with llvm15/16 (and below): https://github.com/google/sanitizers/issues/1501 | |||
| # I cannot reproduce it with the current brew llvm package (18.1.7). TODO: remove when GHA macOS runner image updates the llvm package. | |||
| leak:realizeClassWithoutSwift | |||
|
|
|||
| leak:Curl_getaddrinfo_ex | |||
There was a problem hiding this comment.
Fixes #787
Overview
This started as an additional option to configure, but testing revealed that (some) transports already honor the variable. This PR is now mainly an extensive testing effort to reason about the boundaries & quirks of
http_proxy.One major addition was made to the crashpad handler which now also reads the environment variable if it was set.
TODO
Done
add optionremoved it in favor of relying on transportshttp_proxyfrom environment variables sentry-docs#12424)options->proxyto "")